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 [email protected].
To post to this group, send email to [email protected].
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
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/groups/opt_out.
