Got it. So here are my thoughts on this, none are particularly Cayenne-specific...
Many years ago when I started working as a programmer, I borrowed the domain-centric style from the colleagues I was working with at that time. All the data access code was placed in domain objects. This code was a mix of static and instance methods. This was a very domain-oriented API and it made a lot of sense. Not for long though. In bigger systems, when a single model object is reused in many different "contexts", a few serious issues emerged: * You can't override a static method to behave differently in a different context. * You can't inject dependencies in a DataObject or a static method. Your choices are passing the dependencies as method parameters (gets unwieldy quickly), or resolve dependencies inside the method itself (which makes your code extremely inflexible, often impossible to test). This realization coincided with the advent of dependency injection technology, and DAOs (or more generally - services) suddenly started to make sense. With DI-managed services you can write a few common interfaces and tweak the implementation according to your needs in a specific context. The most common "special" context is a unit test environment. And suddenly all your code is testable in isolation, cause you can mock the dependencies. But history is a spiral that keeps returning to where it's been before, though at a slightly different level :) . Watching the evolution of service-heavy architectures with anemic models, I saw them hitting the ceiling of complexity. This is a much higher ceiling, but never the less. The solution that I am seeing to that is avoiding a "master model", and instead allow some model duplication between multiple "contexts". In simpler terms, if your model scope is small enough, you don't need to override a static method. And now you can maintain a proper ratio of logic between domain objects and services. BTW, LinkETL tool discussed in the parallel thread came from that concept of smaller models. The idea was to have smaller more targeted database schemas as opposed to one huge DB that serves a bunch of unrelated apps within the same enterprise. To summarize, both domain-centric and service-centric architectures have their advantages and downsides. In an ideal world there should be just the right mix of the two. Achieving that can be hard sometimes, and the actual proportion depends on the scope of the system and the tools that you have in your possession. Andrus > On Jun 8, 2015, at 7:39 PM, Tony Giaccone <anthony.giacc...@nytimes.com> > wrote: > > Andrus, > > My point was not so much to generate examples or pointers to examples but > more to talk about the way people are using Cayenne and some thoughts about > the relative advantages of each design pattern. > > > Tony > > On 6/8/15 10:52 AM, Andrus Adamchik wrote: >> Here is a very simple example of DAO-like service oriented architecture with >> Cayenne: >> >> https://github.com/andrus/wowodc13 >> >> Andrus >> >> >>> On Jun 8, 2015, at 4:57 PM, Mike Kienenberger <mkien...@gmail.com> wrote: >>> >>> I tend to use a DAO pattern in projects where I want all cayenne >>> references isolated to a specific package. I use the template >>> generator to create 90%of the code and keep it up to date >>> >>> >>> On Mon, Jun 8, 2015 at 9:48 AM, Gmail <tgiacc...@gmail.com> wrote: >>>> >>>> I'm wondering how people on this mailing BG list structure their Cayenne >>>> projects. The two most common design patterns I have seen are DAO style >>>> where the code that implements access is in its own class and Active >>>> record style where the Domain object implements the data access layer. >>>> >>>> Are most folks here using one of these two patterns or something else all >>>> together? >>>> >>>> Tony Giaccone > >
