On 1/21/11 9:31 AM, Juliusz Gonera wrote:
Rob Miller wrote:
for the record, there are lots of folks who disagree with this
statement. while there are certainly cases where the extra abstractions
that you detail below are useful, IMHO they're overkill for most
applications, which are only intended to work w/ a single persistence
engine and which gain little benefit from the added complexity.
I'm also a bit scared of this because I don't want my Pylons app to look
like Spring or EJB app ;) It looks a bit like the anemic model
anti-pattern:
http://martinfowler.com/bliki/AnemicDomainModel.html
I mean, making separate manager object could be useful, but I'm 99% sure
that I won't replace SQLAlchemy with something else.
I just remember reading that using SQLAlchemy queries makes transition
to Pyramid harder.
do you happen to remember where you read this? i wouldn't think this
would be the case. while the sqlalchemy idioms used in the
documentation and/or paster templates might vary a bit btn pylons and
pyramid (specifically pyramid usually shows the use of the repoze.tm2
middleware to handle transaction commits), neither framework actually
has any formal opinion about how persistence should be handled, and i
can't think of any reason why you'd have to make any significant changes
to how you interact w/ the database when porting from one to the other.
This also isn't something I would worry about, but I
just wondered if using the Session object in model is actually a bad
practice.
i don't see anything inherently wrong w/ it, as long as you're willing
to accept the repercussions: you'll be more closely tied to sqlalchemy,
and you'll have to either provide or mock a database session in order to
test your models.
-r
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" 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/pylons-discuss?hl=en.
