Personally, I've found that many times the logic and object structures that I'm dealing with in my service layer do not directly correlate to my SQLA Objects. This usually caused my SQLA Objects to become bloated with logic and many times these objects become awkward to use. Plus, this also meant that a lot of my business logic was being into the persistence layer (SQLA Objects) violating the principle of separation of concerns. My recommendation is this: strictly use SQLA Objects for persistence only (unless your project is relatively small) and use separate model objects (not dictionaries) to encapsulate behavior and pass around to your service layers. The one disadvantage to this approach can be the redundancy between your domain objects and your SQLA Objects, but I find it's still much easier to test individual components and easier to handle the differences between your persistence model and your domain model.
On Thu, Jun 9, 2016 at 11:33 AM, Iain Duncan <[email protected]> wrote: > Thanks for the input everyone. One thing I'm wrestling with is whether to > use my deserializer/validator to go to app-level dicts or straight to > SQLAlchemy objects. I'm not sure yet whether the service/action layer > should work with SQLA objects all the time. Thoughts on that? > > thanks > iain > > On Thu, Jun 9, 2016 at 10:43 AM, Jonathan Vanasco <[email protected]> > wrote: > >> In our largest app we have a caching layer and do a lot of transitions >> between SqlAlchemy and a Dict (both directions) >> >> some of these may apply to you: >> >> 1. dicts are wrapped in an 'attribute safe' container, so they behave >> like sqlalchemy objects. certain sqlalchemy relationships are handled via >> lazyloading cache items from a readthrough cache. >> >> 2. there is a per-request local cache of dict objects. >> >> 3. the dict containers have a 'readonly' flag, so they raise errors if we >> try to write. the system loads a fresh sqlalchemy object when it needs to >> write, then updates the cached items. >> >> 4. there is a single method for converting the objects from one type to >> another. after a while, it made more sense to keep the mapping logic >> between the two object types instead of nested into one. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" 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]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/pylons-discuss/2a6a8c2d-1d00-4ba9-b99e-2de88be16d56%40googlegroups.com >> <https://groups.google.com/d/msgid/pylons-discuss/2a6a8c2d-1d00-4ba9-b99e-2de88be16d56%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/pylons-discuss/CAN9NcLz8rjPTHK8wFrG97Hnx-UBB_K7GJ97UUZRSTb4WOZA6hA%40mail.gmail.com > <https://groups.google.com/d/msgid/pylons-discuss/CAN9NcLz8rjPTHK8wFrG97Hnx-UBB_K7GJ97UUZRSTb4WOZA6hA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Vincent Catalano Software Engineer and Web Developer, (520).603.8944 -- You received this message because you are subscribed to the Google Groups "pylons-discuss" 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/CAEhnOszCW%3D1NgYm6hA6XaCmYb_U-LyZ-_%3DuN%2BaXCq-Z5P%2BMuuA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
