Comments on: Regarding JPA – is the EntityManager a DAO…

By: Sudhakar Ramasamy

Sudhakar Ramasamy — Fri, 09 Oct 2009 15:08:20 +0000

I think the key word is “CRUD apps”. How many apps have you worked on that are strictly data-entry (create, retrieve, update, delete)?

I had a recent experience where a service class was mixing business logic code with data access code using a DAO. To begin with the class was clearly responsible for two different things.

The moment I had to add some additional processing in the data access code, the class was beginning to bloat. So I extracted the data access code into it’s own service and dao layer and immediately the code became clearer. So I did exactly what this post suggests we may not have to. But then again this wasn’t strictly a “CRUD app”. There was business logic.

By: Jim Chrystal

Jim Chrystal — Wed, 16 Sep 2009 16:00:08 +0000

I think we’re on the same page, Paris. In my prior post I advocate the use of a service layer… just not a separate DAO layer. And, of course, all services would implement interfaces, so swapping out service implementations would be possible to achieve the desired polymorphic effect. I would also venture to guess that swapping out a relational database and ORM tool for a Lucene index is probably going to affect all layers of the application, so I don’t know how much of this work could’ve been mitigated by a DAO layer. That remains to be seen. Lastly, whether or not Java is the CRUD platform of choice is probably fodder for another thread – I invite you do start such a thread, as I would likely contribute

By: Paris Holley

Paris Holley — Wed, 16 Sep 2009 13:51:38 +0000

I agree that in common space now, this really seems like a waste. To put things in perspective however, take a project that I am working on. Built on an older hibernate/spring a few years ago, there was no use of a service/dao layer ( or interfaces for that matter ). Now, there are areas where we want to move form the database to a lucene index, and cannot easily swap out an implementation without breaking functionality. You are right, many CRUD applications will simply pass through to the DAO, but I am all for less logic in your presentation layer. Even if you have a billion getByxxx methods that use the query by example ability in the DAO, its not going to clutter your view classes. Beyond that, should also ask yourself…If all you are doing is dumb CRUD, is Java ( the language ) your best platform?

By: Jim Chrystal

Jim Chrystal — Tue, 15 Sep 2009 18:32:51 +0000

Fair enough. However, I’m still leaning towards the use of the service layer – just nixing the DAO layer. Putting the code in the service has the potential for reuse with a minimal coding penalty, IMHO.

By: Travis Klotz

Travis Klotz — Tue, 15 Sep 2009 15:29:17 +0000

If I’m writing a view that uses a one or more one-off queries to load the data for the view, I have become a big fan of just injecting the SessionFactory directly into the controller and just getting the work done. I have wasted too many hours writing calls to service layers that to nothing but make calls to DAO’s that do nothing but encapsulate a query that is used in exactly one place. Most things we do in Enterprise applications are not as reusable as we would like to think.