Home

News: Simplifying the Data Access Layer with Spring and Java Generics

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

    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

    Threaded Messages (16)

  2. Alternative libraries[ Go to top ]

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

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

  3. Alternative libraries[ Go to top ]

    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

  4. Thumbs up for Spring Data[ Go to top ]

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

  5. Alternative libraries[ Go to top ]

    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.

  6. Why DAO?[ Go to top ]

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

  7. Why DAO?[ Go to top ]

    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

  8. Why DAO?[ Go to top ]

    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

  9. Why DAO?[ Go to top ]

    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

  10. Why DAO?[ Go to top ]

    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

  11. Why DAO?[ Go to top ]

    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

  12. Why DAO?[ Go to top ]

    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.

  13. Why DAO?[ Go to top ]

    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.

  14. Why DAO?[ Go to top ]

    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.

  15. Why DAO?[ Go to top ]

    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.

  16. Why DAO?[ Go to top ]

    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.

  17. Alternative libraries[ Go to top ]

    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.