MVC and django fundamentals

Question

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

Answer 1

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.

Answer 2

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

Answer 3

"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.