My web application is written using Spring MVC + Hibernate.
- My model is "Customer" entity POJO.
- I have got a DAO object "CustomerDAO", its method "saveCustomer(c)" contains the code interacting with Hibernate;
- Then I created a " CustomerService with a "saveCustomer(c)" method who simply pass the customer object to the dao for saving;
- Finally there are "CustomerController" and customer.jsp, who are responsible for the view layer, the jsp's form fields are bound to a Customer object on the controller side. The controller calls the service.
I saw a lot of applications follow this (best) practice but I'm wondering why I would need a service layer.
Maybe it's useful for decoupling purpose: I can show a universal facade to the controllers and inject into the service HibernateDAO, GaeDAO, MyDAO, and so on.... But I could do that without the service, too: using an interface.
I also tought: validation. I'll make my Customer validation in the service but.... it's much more convenient to validate in Spring controller.
Help me understand the concept please :)
Source: Tips4all, CCNA FINAL EXAM
You don't need a service layer. However it helps you to
ReplyDeleteDecouple your components
You can enforce specific business rules in your service layer which should be agnostic to your repository
Let a service facade one or more repositories. Let's consider the following sample
class Service {
private DatabaseBarRepo barRepo;
private DatabaseFooRepo fooRepo;
@Transactional
public void serviceRoutine() {
barRepo.doStuff();
fooRepo.doStuff();
}
}
Here we let two separate repositories take part in the same transaction. This is specific for databases albeit the principles are valid for other systems as well.
The key is the transactional behavior. If you don't have a service layer, where will you demarcate transactions?
ReplyDeletein the presentation layer: that's not where transaction demarcation belongs, and you wouldn't be able to use declarative transaction demarcation
in the DAO layer: you would not be able to create a customer and its contact (for example) in a single transaction, because it would use two different DAOs
Moreover, you want your UI layer as simple as possible, and the business code (which sometimes is much more complex than sinply calling a DAO method) isolated in specific components. This allows
unit testing the UI layer by mocking the service layer
unit testing the service layer (the business code) by mocking the DAO layer
Right now, your service layer is trivial because your service is a trivial wrapping around database accesses. Is that all the app is? If not, when you start building the non-trivial parts, your service layer will expand.
ReplyDeleteYou can save the verbosity by having a BaseService which has all the CRUD operations, delegating to a BaseDAO injected in it.
ReplyDeleteApart from CRUD, almost everything else has separate logic for the business logic and for the database-specific operations. And another thing - you can have a transaction span multiple database operations by annotating the service-layer methods with @Transactional
There are other things that you at service layer. Sometime its about applying business rules before passing any action to DAO. Sometimes one service needs to interact with other services, DAO for the business rules requirement.
ReplyDeleteTell us how you'll do without server layer and with an interface..high level idea, will help me to tell you more.