64

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/

60

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.

  • 1
    I agree with the separation of service and dao layers and your service layer containing your business logic. – Peter Delaney Jun 12 '15 at 10:43
40

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 add/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.

  • 5
    Hey, thanks very much for replying to my question; that's dedication to your blog! Thanks for the great example, keep writing. – Jeff Feb 26 '14 at 2:57
  • This was bugging my mind for some time and I think experience helps the most in these situations. Thank you. – Utku Özdemir Apr 29 '14 at 11:47
  • I agree with the separation of service and dao layers and your service layer containing your business logic and only would call Dao methods. What about when one of my service methods needs to call another service method. Should I have another abstraction above the service layer that calls multiple service methods? – Peter Delaney Jun 12 '15 at 10:47
  • No. Classes at service layer can have reference of each other (as needed) and they can call required methods. – lokesh Jun 3 '16 at 11:26
11

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.

  • 2
    I'm not sure if that applies to Spring -- there is always a custom DAO that needs to be made for the Model. Maybe your statement "there's almost never a need to write your own DAO" applies specifically to EJB containers/application server? – Don Cheadle Jan 27 '15 at 2:47
  • 1
    Its better to write your own (DAO / DAOImpl), although it will only map to EntityManager - Thats because in the future you can add another DAO implementation without need to change service layer code. – ahmednabil88 May 16 '18 at 10:33
  • @YajliMaclo what's the difference what to change? – Alex78191 May 29 '18 at 15:47
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.

2

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?

  • 3
    I've read Ayende's blog post multiple times now, and just cannot shake the feeling that his design (which I would have agreed with at one point), while true to the spirit of YAGNI, would almost inevitably cost more dev time in even the medium term than it would cost to set up the abstraction of layers in the first place. I wonder if he has changed his opinion on tight coupling between the entire application and NHibernate now that it's even more common for a single application to query multiple SQL, NoSQL and API data sources. – Mr Cochese Dec 11 '13 at 9:47
  • @LennyGodber yes, I know your feeling IMO is better to have the DAO/repository layer because as it has more advantages that disadvantages because as you were saying it is very common to have multiple data sources – Jesus Dec 11 '13 at 11:09
-1

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.

protected by gnat Oct 5 '18 at 5:37

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.