Hibernate and Spring – Dao ,Services

I’ve been reading some tutorials and I could see that most of the MVC implementations

are based on:

1) a dao interface for example “IUserDao”

2) a dao impl of that interface – “mySimpleUserDaoImpl”

3) a service interface for persistance : “IUserService”

4) and a impl – “UserServiceImpl”

is this the best practice? i mean the reason i ask this question is because it seem redundant to have 30 services with getXById(), deleteX(x), createX(x) methods that are doing more or less the same.

please take into account that I’m using spring 3 and hibernate 4, and I decided i will ask this question before i start slamming my keyboard with code

thanks.

Answers:

If you are just starting development, look into Spring JPA. A service should be One-to-Many Repositories (DAO). But I would also not create all of that boilerplate code by hand anymore. Spring JPA eliminates the basic CRUD and search functions as well as pagination.

Here is a video that walks through all of the configuration for Spring, JPA, Hibernate, and finishes up with Spring Data JPA showing you all of the boilerplate code that is eliminated.

All of the boilerplate code is now handled for you. You no longer need to create a basic repository class with find methods and basic CRUD functions. The JpaRepository interface offers a lot of nice features and you don’t have do anything for the implementation.

Questions:

Answers:

It´s necessary have dao, daoImpl, service, serviceImpl for each model.

UserDao

UserDaoImpl

UserService

UserServiceImpl

You can use a generic class EntityDaoImpl anf the inteface EntityDao, like this:

No there is no need to have 30 service layers or 30 dao layers.you should specify the layers not considering the Entity wise but the business functionality wise.there can be 5 or 6 entities relevant for certain function and those should be in one layer.But still you will have to have getXById(), deleteX(x), createX(x) in those redundant layers if they are required.

Questions:

Answers:

Creating a separate service for each model is one way to do it, and I have seen real-world applications that do that, but I don’t recommend it. It is overkill for the simple CRUD case and is unhelpful for the more complex cases (where you actually want a transaction to span several DAO calls). It leaves you with a lot of code that doesn’t do much. The DAOs can be specified using Spring Data, the services will be boilerplate with each method wrapping a call to a DAO. Spring should help reduce boilerplate as opposed to mandating it.

If you have a totally CRUD application then you can legitimately do without services, put @Transactional on the DAOs, and call the DAO from the Controller. If the service is not pulling its weight get rid of it.

If you do have actual business logic in the application then when a user invokes something that can involve calls to different DAOs, those calls should usually take place within the same transaction so that if one thing fails everything gets rolled back. (Also creating a transaction is relatively expensive and if you have a controller making calls to different services for different entities then that will be slow.) That is where services come in handy, the service specifies the low-level use cases that the user wants to perform and allows transactional behavior to be specified.

For the CRUD case I would prefer using a tool like Grails or Play or Rails or something to writing Java with Spring MVC. Grails, for instance, will generate views and controllers for you, provide basic data access through GORM (so there are no DAOs to write), and it will let you specify services easily for the cases where you find you need them.