Originally posted by Eric Nielsen:
In almost all the examples I've seen, the service layer is merely proxying calls to the DAO not adding any new features.
Originally posted by Eric Nielsen:
In other projects where I'm able to use an ORM solution, I still commonly end up with a layer of DAOs (based on either Universal (ie type, id arguements and casting required) or Generic implementations (multiple copies of often near identical classes differing only in which type is used to instatiate the DAO). Here's there's often no need (that I've seen) for a repository layer...
The DAOs are returning domain objects, not DTOs. And these domain objects are already complete object graphs.
And I would expect most everything else would live on the domain objects themselves.
I haven't studied DDD, but I suspect that's where my sympathies lie...
Here's a thread where I'm outlining one of my current places where I'm getting in trouble
Originally posted by Eric Nielsen:
So are you implying that with a JPA/Hibernate mapping solution the term DAO is typically inappropriate and the bottom layer in an application is/should be the Repositories (without really changing the default minimum interface exposed)? ... (whether they are called DAO or Repository).
If so I think I would run into circular dependencies as each persisted entities often needs access to some of the other entities persistence handlers
but I still feel like that leads to a very anemic Repository since all its doing is building new items (all updates are taken care of already via the underlying DAO, all searches are already there)
can you show (or point to an on-line example, or suggest a physical book) that illustrates what the data-access layer should look like?
Originally posted by Eric Nielsen:
Thanks. I've ordered that book (and the other DDD one too).
Eliminate 95% of the weeds in your lawn by mowing 3 inches or higher. Then plant tiny ads:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|