Is it necessary for the service layer in a Java EE project to talk to the Entities through a DAO layer?

Question

I am reading this article on EJB 3.0, where the author describes an architecture where the service layer talks to the Entities through a DAO implemented as a stateless session bean.

I am trying to understand why do we need this additional layer.Why can the service layer not talk directly to the entities ? One thought that comes to my mind is - ease of testability. We can test the service layer easily by mocking the DAO's.

Is this the only reason, or are there other reasons as well ?

Answer 1

The idea is to decouple the business logic (or service layer) from the actual persistence strategy. Your entities could be stored, say, in flat files or a database. You should be able to change this persistence strategy without impacting your business layer.

the service layer talks to the Entities through a DAO

This sentence is a bit ambigous. With EJB 3.0, the business entities are POJO. The business layer can use them, and the data access layer as well. The business layer ``talks'' directly to the business entities. But it also talks to the data access layer. The data access layer is responsible of loading and saving the entities mostly.

Transaction demaraction is another concern to deal with. With EJB 3.0, the business layer demaractes the transactions independently of the chosen persistence startegy. The data access layer and the business entities should enforce the transactions of the business layer.

We can test the service layer easily by mocking the DAO's.

Yes. The business layer can be tested using a mock data access layer. The data access layer can be tested without the business layer. Again, this is easy because the business entities are POJO that can be used by either layers. The information required for to the data access layer is provided via annotations, which are irrelevant for the business layer, but do not impose constraints on the modelling of the business entities from the business point of view.

Answer 2

DAO is an abstraction over how to access database using objects. In the original practice of DAO, first there comes an interface defining the operations that you expect from your database:

interface ModelDao {
  Model load(Long id);
  Long save(Model object);
}

Which can be generic or in any way that suits your design. Apart from the high degree of testability of interfaces, DAO pattern adds another advantage that now you can have different technologies implementing the same DAO pattern. Through time, you may need to switch from EJB to Spring JDBC or any other changes.

While all this happens, the service layer still and only sees the data layer through DAO interface. The implementation is always encapsulated from service layer. Additionally, it also increases the testability of service layer through mechanisms such as mocking.

If service layer directly starts to deal with data layer, it means that service layer becomes implementation specific which reduces modularity and coupling of concerns apart from making it harder to test the service layer only for the business logic.

Last but not least, although it's always the best to stick to the original practice, it depends on the size and intentions of your product/project to adopt the approach.

Answer 3

One thought that comes to my mind is - ease of testability

No it's not there just for ease of being able to test the DAO layer. Purpose of DAO in this case is to separate the concern.

@ewernli and @nobeh have explained the purpose of DAO layer etc. I would like to add, it's one of the approaches to solve the problem. Rather in Java world this approach of using explicit layer of DAO has been there for quite sometime. There are alternate approaches that one can implement. For example take the case of ActiveRecord in Ruby/RoR world.

Why can the service layer not talk directly to the entities?

Yes you can design your application such that service layer talks to entity directly. There has been certain set of people who advocate against having DAO and suggest to use Domain Driven Design.

My personal opinion about the whole idea of having a different layer for persistence is kind of annoying. In the approach you pointed at, there entity(ies) are merely acting as data structure or blob to store information(getters and setter). They don't add business logic, most of the time.