On Fri, Jan 8, 2016 at 12:55 AM, Torsten Irländer <tors...@irlaender.de> wrote: > But I wasn't aware of that > this > could be a topic for a talk. Actually I thought this is kind of a hack but > is > seems to be not bad :D.
Organizing business logic has been a perennial issue for Pyramid and Pylons developers forever. I started with high-level class methods and instance methods in the ORM classes (depending on whether it's operating on a single record or querying multiple ones), but I did all the updating in the views. That led to two problems: the model modules became large and cumbersome, and the views had so many unrelated things intertwined. For the model problem I first extracted the searching routines to separate classes in the model (SomethingQuery classes). Another thing I've long disliked was mixing presentation code and data code in the views (Pylons controllers). The only choice was to put formatting code in the Mako templates, and then if there's an exception the traceback was often too generic and wouldn't tell you where, or in the views with other stuff. Again I went maximum-template approach, then minimum-template (a la mustache), then in between. Later I was inspired by Mike Merickel's pyramid_services and the Model-View-Presenter  paradigm. I tried pyramid_services but couldn't find a good reason for adding the complication of the registry class-matching stuff. So I ended up making my own service classes that the views instantiate directly. The services handle business logic, and the views focus mostly on Pyramid interaction (form input, rendering variables). I try to keep Pyramid-specific and presentation-specific things out of the services, with three minor exceptions. One, services have a 'from_request' class method that extracts their data from the request (e.g., database sessions using reified properties, engines using "global" registry attributes). Two, they sometimes raise an HTTPException if the caller would just do that anyway. I figure unit tests can deal with an HTTPException as easily as some other exception. Three, I sometimes have model methods or service methods return a presentation-friendly value (JSONable dict, formatted string) to avoid duplication and put the formatter close to the data fields.  https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter -- 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 firstname.lastname@example.org. Visit this group at https://groups.google.com/group/pylons-devel. For more options, visit https://groups.google.com/d/optout.