On Tuesday, August 13, 2013 12:59:57 AM UTC+3, Ams Fwd wrote: > > On 08/12/2013 02:50 PM, George Sakkis wrote: > > Hello everyone, > > > > this is more of a code architecture and design question but I'm > > wondering what the best practices are regarding declarative models. On > > the one extreme, models are pretty barebone, with little more than the > > columns, relationships and possibly a few declared attributes and > > properties (python and/or hybrid). On the other extreme, models are > > much heavier, encapsulating pretty much the "business logic" of the > > application in methods (and classmethods or staticmethods for querying > > the database). Between these two extremes are models with some common > > or important business logic kept inside the class and the rest defined > > elsewhere (where this "elsewhere" might be the "controllers" or "the > > resource layer" or the "Data Access Objects" or whatever the > > nomenclature happens to be). > > > > So where should the line be drawn between what belongs in a > > declarative class and what not? For example, I suspect that models > > should be completely decoupled from the Session; any Session-related > > code (for querying/updating/deleting objects) should not live inside > > the declarative class. Still I haven't seen this being mentioned > > explicitly in the docs and can't put my finger on it. > > > > Any insight would be appreciated. > > > > Thanks, > > George > > > > -- > > You received this message because you are subscribed to the Google > > Groups "sqlalchemy" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to sqlalchemy+...@googlegroups.com <javascript:>. > > To post to this group, send email to > > sqlal...@googlegroups.com<javascript:>. > > > Visit this group at http://groups.google.com/group/sqlalchemy. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > My 2cents: > > Usually I keep the models absolutely barebones (as you suggested). As > far as I am concerned they are not aware of any 'business' logic and > only deal with CRUD operations and perhaps complex CRUD if the need > arises. > > I usually have another abstraction which is generally a factory that > delegates db tasks to the model and deals with all business logicky > stuff, sessions, complex relationships etc. (a bit like Django's > managers but not quite as coupled to the model i.e. the model does not > know about it). > > This has worked quite well for me in the past and although it is a bit > more work is quite flexible. > > HTH > AM >
Yes, this helps and it's close to my experience as well. One thing though - even if "only" dealing with CRUD operations (especially "complex") in the model, it's not barebones any more. For starters you need a reference to a (typically global) Session object. Then you have to decide what, say, a "Model.create()" method should do: does it only initialize and return a new transient object or does it also add it to the session? Or maybe it should call flush() or commit() on top of that? I've been actually trying to dig myself out of a similar hole lately where, to make things worse, the create logic often lives in Model.__init__. In addition to simply initializing a particular object, it may also hit the db to fetch other objects that are needed, instantiate a bunch of new children objects, call flush() and/or commit(), insert a log entry row in another table and more.. So although viewed from the outside it's "just CRUD", it has all sorts of business logic and assumptions bundled with it. Regards, George -- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.
