wood burning stoves*
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes why we need DAO in an enterprise application ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "why we need DAO in an enterprise application ?" Watch "why we need DAO in an enterprise application ?" New topic
Author

why we need DAO in an enterprise application ?

Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
suddenly I don't understand why we need DAO module. I carefully read the J2EE tutorial Duke Bank Sample Application, it doesn't use any DAO class, persistence entity unit is directly injected in the Service class using annotation. In the enterprise application, tech track, (JSF+EJB+JPA), doesn't need any flexibility in DAO layer, can't imagine JDBC will be used in the Enterprise application.

Do you have any good reason why we need DAO in an enterprise application ?

Thanks
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
The EntityManager can be argued to be a DAO.
Whether you should have a DAO or not when using JPA has been debated many times. The answer obviously depends on the application.

Some reasons why one would prefer to have a a DAO over the EntityManager are:
Let's say it is decided that every call to update data should result in a log entry being created somewhere. If you used a DAO over your EntityManager then you have one place to add the logging logic. If you can intercept the EntityManager methods then this argument is void.
Another reason for adding the DAO could be separation of concerns. Dealing with the EntityManager in only one class in your project can result in more readable business logic (most especially in the few cases when the transactions are user managed).
In corporates, database vendors don't change much but sources of data sometimes do change. If you used a DAO and it is decided that you must now fetch some values from another system via a web service call then you have one place to change


James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1012
    
    5

Edward

Imagine your service (business) layer performing some logic before wanting to persist some change to the database. This layer shouldn't have to worry about JDBC, JPA or EntityManagers. It should simply make a call that says "persist this, I don't care how you do it". By introducing a DAO (which should be injected with the EntityManager), the service layer simply passes this responsibility onto the DAO.

By doing this, if the database moved or data is now saved to disk etc, the service layer does not need to change, only the DAO does.

From experience however, it is tricky to ensure changes to the data tier do not propagate upwards.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Oh and because this is in the SCEA forum, the DAO increases
Mantainability because concerns are separated so code is easier to read and apply fixes.
Testability because you can easily mock out the data access logic to test your services without worrying about database dependencies .
Reusablity because you can call a DAO routine from multiple services also, testable code results in reusable code.

Performance and manageability can be negatively affected.
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
what kind of code we need to put into DAO class ? in most cases, we just delegate tasks to entity manager to do save, update and delete. I do see two areas, one is create JPL based on parameters, another one is create value list. but we need to put value list into session, so I still think DAO is not a good place to do this.

As James said, we need DAO if we decide to save data into disk instead of database, I agree that this is strong reason, but it is a rare case.
James Boswell
Bartender

Joined: Nov 09, 2011
Posts: 1012
    
    5

Edward, whether you call it a DAO, a repository, data object etc, it doesn't really matter. Anything related to saving, updating or retrieving data from some persistent store should be in this object (or tier), leaving your service tier free for business logic only.
E Armitage
Rancher

Joined: Mar 17, 2012
Posts: 892
    
    9
Edward Chen wrote:...
As James said, we need DAO if we decide to save data into disk instead of database, I agree that this is strong reason, but it is a rare case.

It is not the only reason one would have a DAO, see my replies above for the other reasons.
saad el khlifi
Greenhorn

Joined: Nov 07, 2013
Posts: 1

Think about the Testability
You can apply Junit (or other tool) integration test on the DAO layer, while in the business layer you do Junit unit test by mocking the dao dependencies.
By this way you can test easy & best, have a good coverage, and be sure that your components are rebust and of course reusable.
Edward Chen
Ranch Hand

Joined: Dec 23, 2003
Posts: 798
Testability is strong justification. thanks.
 
wood burning stoves
 
subject: why we need DAO in an enterprise application ?
 
Similar Threads
DAO ?
DAO implementation questions
why we need EJB ?
[Resolved] Services as Managed Beans
DAO Pattern