Regarding JPA – is the EntityManager a DAO…

Do we really need ServiceInterface, ServiceImpl, DaoInterface, and DaoImpl? Or can we just say the EntityManager is the DAO, and blow away a generally unnecessary layer? On CRUD apps, 9x out of 10, the service layer is merely a pass-through to the DAO. Is there time to be saved here?


  1. 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.

  2. 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.

  3. 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?

  4. 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 🙂

  5. 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.

Comments are closed.