This is the second of a series of articles about Persistence with Spring. The previous article discussed setting up the persistence layer with Spring 3.1 and Hibernate, without using templates. This article will focus on simplifying the Data Access Layer by using a single, generified DAO, which will result in elegant data access, with no unnecessary clutter. Yes, in Java.

The Persistence with Spring series:

• Part 1 – The Persistence Layer with Spring 3.1 and Hibernate
• Part 3 – The Persistence Layer with Spring 3.1 and JPA
• Part 4 – The Persistence Layer with Spring Data JPA
• Part 5 – Transaction configuration with JPA and Spring 3.1

The DAO mess

Most production codebases have some kind of DAO layer. Usually the implementation ranges from a raw class with no inheritance to some kind of generified class, but one thing is consistent – there is always more then one. Most likely, there are as many DAOs as there are entities in the system. Also, depending on the level of generics involved, the actual implementations can vary from heavily duplicated code to almost empty, with the bulk of the logic grouped in an abstract class.

A Generic DAO

Instead of having multiple implementations – one for each entity in the system – a single parametrized DAO can be used in such a way that it still takes full advantage of the type safety provided by generics.

Two implementations of this concept are presented next, one for a Hibernate centric persistence layer and the other focusing on JPA. These implementation are by no means complete – only some data access methods are included, but they can be easily be made more thorough.

Read the rest of the article

Why even go this route when good libraries exist to have consistent DAO interefaces.

Eg : http://code.google.com/p/hibernate-generic-dao

Also consider using Spring data or Spring Roo which can generate the whole data access code using either a DAO layer or the Active Record pattern.

Zart Colwing

I'd strongly recommend using Spring Data.  It's pretty neat stuff.

I have already used Spring Data extensivelly, and it does what you say and more (my next article covers Spring Data). That is however an added library and may not be the best solution for some environments. This is a simpler, more straightforward way to improve the DAO layer in my view.

Thanks for the interesting comment.

Eugen.

Sorry, I fail to see why I need DAOs at all. Why not simply use the EntityManager directly? No DOA == No DOA mess!

With DAO, say today you are using entityManager, tomorrow you could be using hibernate sessionManager (back) or something else and your changes are restricted only to the DAO. That is a sentence explaination of why we need DAO.

HTH

With DAO, say today you are using entityManager, tomorrow you could be using hibernate sessionManager (back) or something else and your changes are restricted only to the DAO. That is a sentence explaination of why we need DAO.

HTH

With DAO, say today you are using entityManager, tomorrow you could be using hibernate sessionManager (back) or something else and your changes are restricted only to the DAO. That is a sentence explaination of why we need DAO.

HTH

With DAO, say today you are using entityManager, tomorrow you could be using hibernate sessionManager (back) or something else and your changes are restricted only to the DAO. That is a sentence explaination of why we need DAO.

HTH

With DAO, say today you are using entityManager, tomorrow you could be using hibernate sessionManager

Standards body goes around making a standard API, and continues developing it, and you still fear that it will be replaced in the near future? Using a different JPA implementation more than likely

Actually JPA is not everything in the Java persistence world. Just recently I've switched from Hibernate to Neo4J, and the fact that I had a DAO layer in place (based on Spring Data) made the transition relativelly painless.

Thanks for the feedback.

Eugen.

DAO is considered by many an anti-pattern nowadays, still lots of architect still insist on segregating all dataaccess in DAOs. Is it clevers or resistance to changes ?  I, for myself, think that DAOs should be something of the past as I consider that the EntityManger (or Hibernate Session) is THE DAO. Most code in DAO anyway just delegate to the EntityManager.

I mean, most DAO function just delegate to the EntityManager without bringing any value added. Why pay the cost of having to maintain yet another class plus an interface for code that can be stuffed right into a service class.

What the DAO enables you to do is be decopupled of the underlying storage; the DAO should be agnostic of Hibernate and not use Hibernate APIs directly. That is it's purpose, and if that's not something you're interested in, then the EntityManager works fine and you have no need for the DAO. If however you do not want to call Hibernate directly (which can be considered good practice), then you need the DAO and a common interface to work with.

I think you're over-simplifying the situation here. How would you then unit test the service class? Yes, the EntityManager can be mocked but mocking query setup, parameter binding and query execution is quite cumbersome. I'd even argue that when using the Criteria API (which is not the most beautiful API in the very first place) mocking interaction with the EntityManager even becomes what I'd call a PITA. Now compare that to mocking a plain method backing a query with a few parameters.

Beyond that I think that from an architectural or design perspective you don't want to let you EntityManager clients call the EntityManager with each and every domain class to avoid an enchilada of dependencies to a variety of entities everywhere in the codebase. Thus a plain repository interface per root entity (note that you usually don't have repository interfaces for all entities) nicely groups related data access functionality and - if implemented with Spring Data - provides some neat value adds (pagination, no need to implement query execution) out of the box.

I wrote active-collections as an active_record inspired solution to the generic DAO for JPA. It has a couple of nice features: The generic DAO implements the Set interface so you can treat a table of JPA objects as a standard Collection. It also has an api for defining and chaining filters that are lazily executed against the DB.

simplyfying data access layer is always a good thing

sell sheet design

simplyfying for  java is way cool

club stork