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!
"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.
This link will explain the MVC and the likes. This link has all the django related documentation, starter kits etc.
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.
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