On Wed, 2009-04-08 at 12:35 -0700, mettwoch wrote: > Thanks a lot Malcolm! I'll start moving the TurboGears hand-written > admin to the Django admin and keep MySQL. > > I've one more philosophic question: The model in Django should hold > the business rules, right?
Not really. Firstly, I'm kind of allergic to the word "should" in a lot of design discussions, beyond thinking that things "should work" and "should be maintainable", but I understand where you're coming from. Django models are modeling the persistent data storage. They're not Models in the capital-M, MVC sense (which do contain the business logic). There are often methods attached to Django models to make, say, retrieving and saving data, either on the per-instance or table/model-wide level (via model managers) easier. And, in the future there will be data validation constraints possible (there used to be, it wasn't very well implemented so we removed it prior to 1.0, a better version is coming back -- if you don't know the history there). However, business rule validation, which will often cross multiple models for storage purposes, is something that is more at the level of what Django calls view functions (again, *not* MVC views) or other functions called by those views. They can, in fact, be done anywhere you like, but they're not strictly coupled to how the data is persisted. > So let's say that there's a "product" class > that knows to calculate it's "stock" through the addition of stock- > movements. That's coded as a function in the "product" class. That > business rule/algorithm is only available within Django and not in any > other front-end accessing the same MySQL database through ODBC for > instance. Obvious! If business rules have to be available outside > Django then they have to be coded as stored procedures in the database > in yet another language (PL-Sql or whatever ...). That's sort of a > pity. Might there be a technical way to "serve" the database to an > ODBC client through Django? Not as an ODBC interface, no. Or, at least, not particularly easily (Python is a fully fledged, Turing-complete language, so anything is possible, but practical or pragmatic are really the issue here). On the other hand, providing a consistent and useful interface to things is precisely what REST architectural style is about, for example. ODBC is probably the wrong protocol for this and providing broad support for inter-component integration really is about the protocols. HTTP and a sensible HTTP-based vocabulary is something that far more operations speak than anything ODBC based. Ultimately, ODBC isn't a business application protocol, it's a database connection protocol (hence the name :-)), so, much as with Django's models, lives below the layer of the business logic. Trying to force the business logic through that is probably a round peg, square hole operation. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
