• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why we need DAO in an enterprise application ?

 
Edward Chen
Ranch Hand
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1051
5
Chrome Eclipse IDE Hibernate
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1051
5
Chrome Eclipse IDE Hibernate
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 989
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1
Flex Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 798
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Testability is strong justification. thanks.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic