• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

JPA and DAO's

 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Today I was messing around with JPA a bit again, you know, just for fun, because I'm such a big freggin dork. Anyway, my typical pattern for data access is to use DAO's for general queries and a service (business) layer that uses the DAO's and might wrap several queries in a transaction or in general take care of some nastiness that I don't want in my DAO or controller code.

Back in the olden days when it was all JDBC the DAO layer was responsible for getting a connection and handling all the wonderfulness of SQL and Statements and ResultSets. Then I started using iBatis along with Spring's SqlMapClientTemplate and it became a case of the DAO layer doing something like this:



Even that seems too little to warrent an entire class just for lines like that. Spring's templates kind of act as the DAO layer in some regard.

But using JPA its as if the EntityManager is really a general DAO and maybe I should lose my DAO layer all together when using JPA and just use a Service or Manager layer to handle transaction control and business logic. What do others think about this?

My first negative comment about it is you lose the ability to have a truly data access agnostic service layer. However, if you were to change your DAO implementation you are changing code. You might not have to touch your service layer but you would have to touch your DAO layer. As long as you code for interfaces, I think you are still safe to lose the DAO layer all together. All that would change is the service implementations.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here's a good example using a sample application I am working on. I am managing Books. So I have the following:

Book.java


BookManager.java


BookMananagerImpl.java


BookManagerActionBean.java


So where is the down side to this approach? Or rather, what does a BookManagerDAO buy you here?
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you will find that there are still a good idea to use DAOs. But what is cool with JPA and Java 5+ is that you can Genericize the basic CRUD stuff, and in your specific DAO implementations just add what is out of the ordinary for that DAO.

I think the Hibernate docs have a Generic DAO all ready to go, then all you have to do is



I forgot how the EntityManager gets in there, maybe a method parameter, or maybe there was an Abstract class that gets it in the constructor, but there are examples out there.

Hope that helps

Mark
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yea, I've implemented the generic stuff before. It works well.

http://www.greggbolinger.com/blog/2008/04/17/1208457000000.html

I think you will find that there are still a good idea to use DAOs.

Care to elaborate?
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm still trying to find a happy medium myself, but at the moment, I have a small handful of DAOs for single-object persistence and a set of service objects for the stuff that works with more complex relationships (like parent-child-grandchild and cross-linked stuff).

I was using inheritance for a DAO, but dropped it because after I applied things like container injection of the EntityManager, there really was no commonality. I'm not presently using annotation-based finders, however, which might make a difference.

There have been a couple of attempts to genericize DAOs. One worth checking out is Crank, by Rick Hightower, who maintains a blog (Sleepless Night in Tucson) at Jroller.com.
 
author and cow tipper
Posts: 5009
1
Hibernate Spring Tomcat Server
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is actually a very interesting discussion. On the SCEA board, we had a discussion on "Which J2EE Design Patterns are Obsolete with JEE5?" Many people felt the desire to kill the DAO pattern.

I agree that there is great value in separating the data layer from the application layer. I mean, that's just a given. But indeed, POJO based persistence does make the need for making DAOs every time questionable. And the fact that DAOs can be made to be so generic, it again almost begs the questions "what's the point?"

The other thing I find very interesting is that many places using the DAO pattern to hide their implementation layer from the application or service layer typically have a search method that passes in a org.hibernate.criterion.Criterion object. Now correct me if I'm wrong, but doesn't passing a hibernate criterion object defeat the purpose of creating DAOs that hide the implementation layer from the application integrator or service layers? Always makes me giggle.

One thing I will say is that most application integrators are very familiar with DAOs, and if you provide them, they can use them. Even if the only benefit is the ability for JSF or middleware developers to be able to start using them quickly and effectively, well, that's probably a pretty good argument in itself.

I provide a little tutorial on my website on how to create generic DAOs that leverage the good old Java 5 Generics, along with the Factory and ServiceLocator design patterns. Very old school, but the tutorial is a bit simpler than the ones you might see in the Caveat Emptor application. If anyone is interested, it's right here:

Implementing Simple DAOs with Java5 Generics, Hibernate3 and Java Persistence API Annotations (JPA)

-Cameron McKenzie
[ June 13, 2008: Message edited by: Cameron Wallace McKenzie ]
 
Mark Spritzler
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah, what those guys said.

Mark
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes I'm transitioning from the DAO model to the Repository model. The repositories are normally backed by a "Workspace". Ideally the workspace would be implementation agnostic, but I'm willing to consider JPA interfaces implementation agnostic. Since otherwise the custom Workspace needs to wrap the basic generic-DAO-esque calls, plus some query language.

On the surface Repository vs DAO can seem like a trivial distinction, but I'm finding it very helpful in keeping the infrastructure more understandable and less repetitive.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Cameron Wallace McKenzie wrote:
...
I provide a little tutorial on my website on how to create generic DAOs that leverage the good old Java 5 Generics, along with the Factory and ServiceLocator design patterns. Very old school, but the tutorial is a bit simpler than the ones you might see in the Caveat Emptor application. If anyone is interested, it's right here:

Implementing Simple DAOs with Java5 Generics, Hibernate3 and Java Persistence API Annotations (JPA)

-Cameron McKenzie
[ June 13, 2008: Message edited by: Cameron Wallace McKenzie ]



Cameron,

As an author of books you should know better that transaction logic does not belong in DAO layer as you show in your tutorial "The Amazing GenericDAO Interface"?

Andre

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic