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/


6 Answers 6


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. Commented Jun 12, 2015 at 10:43
  • not to mention that 1 service might call several DAOs, for example when saving an user you might talk to the UserDao, the UserOrdersDao, etc Or should we create one service for each? And then who could call all of these services? Commented Oct 25, 2019 at 15:25
  • "Generally" "sometimes" "occasionally"... What type of Scientific answer is this? Commented Apr 20, 2020 at 19:50
  • @YoushaAleayoub if you know how to improve this answer, please do. This is a collaborative site, we all strive to make it better together.
    – Abel
    Commented Sep 5, 2023 at 17:59

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.

  • 7
    Hey, thanks very much for replying to my question; that's dedication to your blog! Thanks for the great example, keep writing.
    – Jeff
    Commented Feb 26, 2014 at 2:57
  • This was bugging my mind for some time and I think experience helps the most in these situations. Thank you. Commented Apr 29, 2014 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? Commented Jun 12, 2015 at 10:47
  • No. Classes at service layer can have reference of each other (as needed) and they can call required methods. Commented Jun 3, 2016 at 11:26

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


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? Commented Jan 27, 2015 at 2:47
  • 2
    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. Commented May 16, 2018 at 10:33
  • @YajliMaclo what's the difference what to change?
    – Alex78191
    Commented May 29, 2018 at 15:47

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.


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?

  • 5
    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
    Commented Dec 11, 2013 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
    Commented Dec 11, 2013 at 11:09

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.

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