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.