cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <>
Subject Re: Cayenne design Patterns
Date Fri, 12 Jun 2015 08:01:36 GMT
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. 


> On Jun 8, 2015, at 7:39 PM, Tony Giaccone <> 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:
>> Andrus
>>> On Jun 8, 2015, at 4:57 PM, Mike Kienenberger <> 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 <> 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
>>>> Tony Giaccone

View raw message