|
David Newton wrote:But now your DAOs are actively involved in transaction management--I don't think they should care how they're being used, that's mixing up concerns. Transaction management should be handled a level higher, either through something like Spring (much cleaner) or manually in services etc.
David Newton wrote:Having the DAOs handle transactions is *not* a clean choice, because the DAOs then have to understand the context in which they're being used. If you're working in an environment that allows nested transactions they don't have to worry about it. If you're not, you're either going to have to add a flag, or have the DAOs understand more than (I believe) is reasonable about the world in which they live.
YMMV.
David Newton wrote:
Honestly, I have no idea what your class diagram looks like, and it sounds over-architected to me, so I doubt I'll be able to provide much more useful input. I don't understand how many layers you have, how they interact, how they're used, why the exist, and so on.
David Newton wrote:Not really, but that's okay.
I always go through a service, even if it's just a delegation to a DAO. This allows me to put aspects around all my service methods and leave my DAOs alone, which in turn means that I don't need to do anything in particular for services that use multiple DAOs, and the service methods that wrap DAO calls can be generated automatically. There's an interface that defines DAO operations, each related service implements the same interface. Services also implement their *own* interface that defines functionality beyond that provided by its underlying DAO. Some services, of course, aren't tied to a single DAO.
I have yet to see a great reason for a facade between controllers and services;
You save more money with a clothesline than dozens of light bulb purchases. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|