Honestly , It depends on how you see the application grow.
I've been doing more of "Choice D" lately-
Choise C - Keep that stuff in the View.
Choice D - Have an "internal API" for methods like "getAllComments";
exposing something like "lib.internal_api.getAllCommentsForBlogentry(id)"
For preliminary views and admin work, using SqlAlchemy with only mapped
relations and association proxies has been perfect.
Something that really made us want to keep the Model slimmed down , and
transition logic into views/libs , is that we re-use our core SqlAlchemy
model across different services [ currently Celery and Twisted ]. If we
had more logic in the model, we'd have to maintain it across multiple
environments AND have a bit of memory bloat. So we've kept SqlAlchemy
classes to only handle the core model ( columns and relations ).
As our application advances, we've run into problems with Performance
Tuning, Result Pagination and Caching. We found it easier to implement a
Read-Through cache with a customized solution , where 'public' objects are
pulled from a cachingAPI that fails onto our internal API. The internal
API mainly queries PostgreSQL, but the underlying datastore for different
objects -- or functions -- can be swapped or even mixed. The results we
return are always interchangable with SqlAlchemy objects, so the code
outside of "lib" never changes from this type of stuff.
For 95% of apps, you won't need stuff like that. Thankfully Pyramid lets
us.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to pylons-devel+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-devel.
For more options, visit https://groups.google.com/groups/opt_out.
