On Monday 27 November 2006 17:34, Jorge Godoy wrote: > "Matt Culbreth" <[EMAIL PROTECTED]> writes: > > So where do people end up putting application logic as described in #3 > > above? I can see three logical places: > > 1. In the model classes (or the classes used by SA in the mapping) > > 2. In the controller classes > > 3. In some Business Logic classes that are a bridge between models > > and controllers. > > I put some of it at my controllers and at the fourth option: inside the > database. > > Everything that the database can handle by itself should be there. This > makes the code smaller on the application and guarantee the robustness of > the information stored there no matter how it got inside the database.
Ahh, well, that is of course _very_ debatable, to say the least. To me, there are quite a few reasons to shy away from triggers and the like: - you lose database vendor independence - on a much larger scale than with the comparably small differences between e.g. postgres and oracle on the pure SQL level - which are handled by ORMs anyway. - having developers understand two programming languages - the database languages are severely limited in what contextual information they can access, as there is no in-process data. Thus you end up storing all kind of volatile data in there, too - even though it might be a question of project leadership, triggers and the like tend to be edited in-place often, and are sometimes not subject to version control at the level they should be. - how do you test this, without sqlite supporting the same trigger languages as e.g. oracle or postgres? This heavily complicates testing. - surprises everywhere - the nature of triggers makes it hard to grasp _what_ actually happens. Don't get me wrong, I'm a friend of magic as well, but in python I can at least follow stuff around in my editor - who knows what runs in the database? - smearing application logic over several layers without any _need_ to do so makes understanding the app considerably more difficult. The applications I've seen that depended on triggers and the like all had one major flaw IMHO: they lacked a proper three-tier abstraction or at least a core library containing the app-logic was missing - and instead communicated over the DB. Which meant that they had different application parts that awfully often went out-of-sync regarding of what they expected to be in the DB, and in what form - with the result that triggers were brought into the game to patch over those gaps in logic. So - if you don't _have_ to do it, don't do triggers. And if you have the chance, design your application with a proper business logic tier, if that is what you need - exposed via an RPC method for example. YMMV of course... -- >> Diez B. Roggisch >> Developer T +49 (30) 443 50 99 - 27 F +49 (30) 443 50 99 - 99 M +49 (179) 11 75 303 E [EMAIL PROTECTED] >> artnology GmbH A Milastraße 4 / D-10437 Berlin T +49 (30) 443 50 99 - 0 F +49 (30) 443 50 99 - 99 E [EMAIL PROTECTED] I http://www.artnology.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
