On Mar 4, 12:21 pm, ruffeo <timdenni...@gmail.com> wrote:
> Does anyone know how to develop a complex django project in a 3 tiered
> network environment, still using the MCV architecture?
>
> I.E. Web Server (view and control code), App Server (model code), and
> Database Server
You have to distinguish between "architecture" as it applies to
different types of objects within a single process (also often called
the MVC "pattern") and architecture as it applies to individual
processes and how they communicate with each other. MVC isn't meant to
describe the architecture between individual processes and how they
communicate.
If you want three physical tiers, each tier can have it's own MVC
pattern (or each one can use a totally different pattern). If the "App
Server" is a representation of the model and is only accessible by web
services, then you need Django Models to represent the database model,
and Django Views to expose those models via HTTP.
Then the "Web Server" would have it's own Django Views which consult
Django Models that are backed by web service calls. Finally you'd use
Django Templates for most views to make it easier to separate the
Python from the HTML. Finally the Views and Templates may themselves
contain JavaScript, and that JavaScript code may organize itself into
some MVC pattern ...
Except Django tightly couples it's schema descriptions of models to a
specific persistance layer. If you wanted to re-use the data
description part of the model between relational database backed model
classes and web service backed model classes, I'm not sure if it's
possible - maybe it can be done with a little (or a lot) of
metaclassery? Most likely you'd want to use an external package such
as zope.schema to allow this further seperation of concerns.
Except I'd say that both the MVC pattern and the Three teired
architecture are both very simplisitic ways of modeling a web
application. They tend to fall apart as you start to tailor them to
what you are actually trying to build, the idea of separating the "Web
Server" and "App Server" onto separate physical servers is kind of a
clunky idea that was popular in the dot com era when you had to deploy
onto 200 Mhz boxes. Today servers are fast enough that it's usually
not an issue to deploy the whole stack on a single server ... but it
all depends upon how big you want to scale up to - for example,
Amazon.com makes this split between "Web/presentation" servers (using
Perl/Mason) and "App/web-service-as-model" servers (using Java/SOAP),
and that type of complexity is probably justified for the scale of
their business.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
