Hibernate: Entity - DAO Interface - DAO Class - Service (is it a good practice?)

Question

I've recently started looking into Hibernate. I've searched for best practices regarding the layer of the Hibernate related classes and one thing that always comes up is the following structure: Each Entity has its own DAO Interface, which in turn has its own DAO implementing class, which in turn has its own Service.

Is this considered to be the best practice? My problem with that is that a lot of code is being repeated or is basically the same for every entity. And frankly, 4 files for each model seems a bit too much to me.

I understand how interfaces for DAOs make changing frameworks and testing easier. And I agree that on some of them you need separation between the DAO and the service (as you want to keep DAO functionality to a minimum and add additional business logic in the service).

But some entities need only simple logic, and the DAO is more than enough for them. Should they still have their own service class? And what if a good number of entities will always need the same basic functionality? Can't their DAOs share a common interface? (instead writing one for each of them)

In conclusion, wouldn't an adaptive approach to each entity fit better or would that break the predictability of the code?

Answer 1

It is good practice to keep each layer separated.You will realize its importance when your application complexity begin to increase.

you can provide a generic super class with common functionality implemented and extend this class to all Entity Implementation classes. This will reduce code repeatation in dao layer.

Answer 2

If you are going to use Hibernate then Hibernate is essentially the DAO and DAO implementation done for you. Also, when you are talking Hibernate I am assuming you mean JPA, especially since the Hibernate criteria api seems to be getting deprecated. I think moving towards JPA is a good idea.

If you have a service layer for each entity then you don't understand what a service layer is. Generally a service layer defines an application boundry, but I like to explain it as a point of view into the persistence domain. So, if management is a client of your application, then you have have a management service layer that handles management business logic (e.g., reports, sales performance, security). The sales service layer might return all the orders a client has while the shipping service layer might return all the order an address has. Your service beans, typically stateless EJBs, will interface to whatever persistence entities it needs to in order to get what it needs.

Hope this helps.