wood burning stoves 2.0*
The moose likes Object Relational Mapping and the fly likes JPA and DAO's Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA and DAO Watch "JPA and DAO New topic
Author

JPA and DAO's

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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.


GenRocket - Experts at Building Test Data
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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?
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

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?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 15952
    
  19

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.


Customer surveys are for companies who didn't pay proper attention to begin with.
Cameron Wallace McKenzie
author and cow tipper
Saloon Keeper

Joined: Aug 26, 2006
Posts: 4968
    
    1

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
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Yeah, what those guys said.

Mark
Eric Nielsen
Ranch Hand

Joined: Dec 14, 2004
Posts: 194
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.
Andre Piwoni
Greenhorn

Joined: Nov 11, 2011
Posts: 1
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

 
It is sorta covered in the JavaRanch Style Guide.
 
subject: JPA and DAO's
 
Similar Threads
stand-alone java app and hibernate transactions
Question on Component Diagram
J2EE Data Access Lyer Design suggestions...
Spring Live
Confusion - CMP vs Session EJB > DAO