Service layer vs DAO -- Why both?

Question

I have been working with SpringMVC, Hibernate, and some databases in a java web application example.

There are a few different ones that do this, but this Spring 3 and hibernate integration tutorial with example has a model class, view (in jsp), and a service and dao classes for the controller.

My question is, don't both the service and DAO classes do the same thing? Why would you need them both?

This was the tutorial I was actually using: http://fruzenshtein.com/spring-mvc-security-mysql-hibernate/

Answer 1

Generally the DAO is as light as possible and exists solely to provide a connection to the DB, sometimes abstracted so different DB backends can be used.

The service layer is there to provide logic to operate on the data sent to and from the DAO and the client. Very often these 2 pieces will be bundled together into the same module, and occasionally into the same code, but you'll still see them as distinct logical entities.

Another reason is security - If you provide a service layer that has no relation to the DB, then is it more difficult to gain access to the DB from the client except through the service. If the DB cannot be accessed directly from the client (and there is no trivial DAO module acting as the service) then all an attacker who has taken over the client can do is attempt to hack the service layer as well before he gets all but the most sanitised access to your data.

Answer 2

I am the writer of post in question. I have got my fair share of working on different technologies and different architectures.

Based on above, I can safely say that having Service layer and DAO layer is always a good idea.
DAO should be limited to only remove/update/insert/select Entity objects into/from database and that's all. If you want to do anything extra in terms of logic, add it to Service layer. This will help in making code modular and easily replaceable when database is replaced (for some part of data). This is specially applicable in applications involving reports which have heavy logics even after fetching data from database.

Also, in Spring, security is applied at service layer ideally. You would not like to change this way.

Answer 3

Adam Bien points out in his book the fact that the JPA EntityManager is a good universal implementation of the DAO:

http://realworldpatterns.com/

In the Java EE world there's almost never a need to write your own DAO because JPA implementations include one. You only have to write the service layer.

Implementing your own DAO layer is really a hangover from the very poor J2EE architecture of 15 years ago, but many people still feel compelled to do it. These custom DAO layers often provide nothing more than forwarding functions that call the corresponding method on EntityManager.

So to answer your question, yes you need a service layer and a DAO, but you only have to write the service layer.

Answer 4

I usually put all db specific code (queries) in DAO's and transaction handling and business logic in services. This allows for service methods to invoke methods across multiple dao's and keep it all within same transaction. In my opinion, this is allows for better code reuse across dao's.

Answer 5

I have found that the service layer adds unnecessary complexity in most cases. In theory is to avoid to have businesses logic in the dao layer but at the end this just lead to confusion, even some people have disused to remove completely the dao layer as they feel it does not add value. http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer

But if you have multiple business logics then yes It is a good idea. How essential is it to make a service layer?

Answer 6

IMHO the Service layer can be considered as a layer between the controller and DAO layer. This service layer is exactly where we can add business logic and even create a return object specific to what needs to be rendered by the view.