views:

708

answers:

5

Pretty new to this scene and trying to find some documentation to adopt best practices. We're building a fairly large content site which will consist of various media catalogs and I'm trying to find some comparable data / architectural models so that we can get a better idea of the approach we should use using a framework we've never made use of before. Any insight / help would be greatly appreciated!

A: 

how about using what you know and quit worrying about being buzz-word compliant. welcome to stackoverflow by the way

+7  A: 

"data / architectural models so that we can get a better idea of the approach we should use using a framework we've never made use of before"

Django imposes best practices on you. You don't have a lot of choices and can't make a lot of mistakes.

MVC (while a noble aspiration) is implemented as follows:

  • Data is defined in "models.py" files using the Django ORM models.
  • urls.py file maps URL to view function. Pick your URL's wisely.
  • View function does all processing, making use of models and methods in models
  • Presentation (via HTML templates) invoked by View function. Essentially no processing can be done in presentation, just lightweight iteration and decision-making

The model is defined for you. Just stick to what Django does naturally and you'll be happy.

Architecturally, you usually have a stack like this.

  • Apache does two things.

    • serves static content directly and immediately
    • hands dynamic URL to Django (via mod_python, mod_wsgi or mod_fastcgi). Django apps map URL to view functions (which access to database (via ORM/model) and display via templates.
  • Database used by Django view functions.

The architecture is well-defined for you. Just stick to what Django does naturally and you'll be happy.

Feel free to read the Django documentation. It's excellent; perhaps the best there is.

S.Lott
If you're concerned about performance or memory usage, it's often better to have a separate lightweight webserver (such as Nginx) for serving static content, rather than using Apache for both (though you can get similar effect if you use mod_wsgi in daemon mode and Apache worker MPM).
Carl Meyer
@Carl Meyer: or lighttpd for serving static content.
S.Lott
+1  A: 

This link will explain the MVC and the likes. This link has all the django related documentation, starter kits etc.

Perpetualcoder
from the link: "Probably the widest quoted pattern in UI development is Model View Controller (MVC) - it's also the most misquoted."
Javier
+1  A: 

first, forget all MVC mantra. it's important to have a good layered structure, but MVC (as defined originally) isn't one, it was a modular structure, where each GUI module is split in these tree submodules. nothing to use on the web here.

in web development, it really pays to have a layered structure, where the most important layer is the storage/modelling one, which came to be called model layer. on top of that, you need a few other layers but they're really not anything like views and controllers in the GUI world.

the Django layers are roughly:

  • storage/modelling: models.py, obviously. try to put most of the 'working' concepts there. all the relationships, all the operations should be implemented here.
  • dispatching: mostly in urls.py. here you turn your URL scheme into code paths. think of it like a big switch() statement. try hard to have readable URLs, which map into user intentions. it will help a lot to add new functionality, or new ways to do the same things (like an AJAX UI later).
  • gathering: mostly the view functions, both yours and the prebuilt generic views. here you simply gather all the from the models to satisfy a user request. in surprisingly many cases, it just have to pick a single model instance, and everything else can be retrieved from relationships. for these URLs, a generic view is enough.
  • presentation: the templates. if the view gives you the data you need, it's simple enough to turn it into a webpage. it's here where you'll thank that the model classes have good accessors to get any kind of relevant data from any given instance.
Javier
+1. Exactly right.
Carl Meyer
A: 

To understand django fundementals and the django take on MVC, consult the following: http://www.djangobook.com/

As a starting point to getting your hands dirty with ... "...trying to find some comparable data / architectural models"

Here is a quick and dirty way to reverse engineer a database to get a models.py file, which you can then inspect to see how django would handle it.

1.) get an er diagram that closely matches your target. For example something like this http://www.databaseanswers.org/data_models/product_catalogs/index.htm

2.) create an sql script from the er diagram and create the database, I suggest Postgre, as some MySQL table type will not have forgien key constraints, but in a pinch MySQL or SQLITE will do

3.) create and configure a django app to use that database. Then run: python manage.py inspectdb

This will at least give you a models.py file which you can read to see how django attempts to model it.

Note that the inspect command is intended to be a shortcut for dealing with legacy database when developing in django, and as such is not perfect. Be sure to read the following before attempting this: http://docs.djangoproject.com/en/dev/ref/django-admin/#ref-django-admin

pcn