...And Finally, You Should Introduce A DAO If:
- Your Services will not just degrade to a plain delegates after the DAO-introduction.
- You are really going to mock out the DAOs and test the Services (really = high code coverage of Service layer with serious unit tests).
- It is likely, that your persistence implementation will change next time (<few years).
- Your DAOs is not just a wrapper around the EntityManager - it provides additional value (fluent interface, query builder, domain specific queries etc).
- Your design remains DRY and KISS.
What's KISS?:
| Keep it Simple, Stupid |
| Keep it Simple, Silly |
| Keep it Simple, Shithead |
| Keep it Simple & Stupid |
| Keep it Small & Simple |
| Keep it Sweet & Simple |
| Keep it Simple & Straightforward |
| Keep it Simple & Smart |
| Keep it Strictly Simple |
From wikipedia. |
I really like it this way !
Posted by Stefan Hansel on February 16, 2009 at 10:19 PM CET #
What about always encapsulating your elementary data access operations into DAOs and leave out the Service bean in case it's a plain delegate? I think it's a similar approach as yours but with less refactoring and more consistent naming at the end.
Posted by Kristof Jozsa on February 17, 2009 at 09:18 AM CET #
Kristof,
exactly, this is what I called "collapsed" in my previous post: http://www.adam-bien.com/roller/abien/entry/daos_aren_t_dead_but
thanks!,
adam
Posted by Adam Bien on February 17, 2009 at 12:22 PM CET #
I'm all for keeping things simple however I wouldn't be too quick to remove all DAOs entirely. Even when using a good ORM framework or an OO db I still tend to have a bit of code to massage the objects into and out of the db. Should these methods be in the domain objects obscuring your business logic? If the DAO becomes too thin I can understand it being an overhead but when I've started a project without DAOs I've tended to end up changing to use them as the complexity increases and the benefits of DAO separation increase.
Having said this I'm always re-evaluating my approach and perhaps I'll come round yet :)
Just a thought, how about one DAO shared between a logical group of related domain objects? Does this go against the principles of the pattern too much or is it a practical modification?
Posted by Pete C on February 17, 2009 at 01:45 PM CET #
I've normally felt that having a service layer with as little as possible in it is a good thing. The purpose of the services then becomes largely about demarking your transactions and minimal coordination of your domain objects. A thin service layer can indicate that the system's logic has been pushed down into the domain objects where it can more naturally be reused.
I like your blog by the way, I've only recently come across it, it's been duly added to my regular feeds. Cheers
Posted by Pete C on February 17, 2009 at 01:54 PM CET #
Hi Pete,
...and I like your comments! :-)
thanks for your feedback,
adam
Posted by Adam Bien on February 18, 2009 at 12:47 AM CET #
Hi adam,
I've read your mentioned post but I'm still unclear on your suggested approach. I guess the more I read these posts the more unclear I become about your standpoint :)
For commenting the original suggestion, while I'm absolutely biased towards KISS, I still would not 'pollute' the service layer by using entitymanager directly. It goes way into low-level details and hurts something Kent Back describes as the 'Symmetry' pattern (eg. dont mix high and low level stuff together).
Besides, I absolutely agree with Pete C about keeping the service layer minimal and go for DDD whereever you can. As for Pete's suggestion, I think sharing a DAO between more domain objects is a good approach. In fact, DDD even suggest thinking in Aggregates ("An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes").
As a last technical comment, I'm afraid new comment email notification doesn't appear to be working here.. Adam can you please have a look? And before I forget, thanks for your blog, it's really one with excellent insight - keep up the good work :)
Posted by Kristof Jozsa on February 19, 2009 at 09:02 AM CET #
I've read your mentioned post but I'm still unclear on your suggested approach, but I still would not 'pollute' the service layer by using entitymanager directly. It goes way into low-level details and hurts something Kent Back describes as the 'Symmetry' pattern (eg. dont mix high and low level stuff together).
Besides, I absolutely agree with Pete C about keeping the service layer minimal and go for DDD whereever you can. As for Pete's suggestion, I think sharing a DAO between more domain objects is a good approach. In fact, DDD even suggest thinking in Aggregates ("An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes").
Posted by Kristof Jozsa on February 20, 2009 at 09:11 AM CET #