Do I really need a service layer?

Question

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 :)

score 25 · Accepted Answer · edited Mar 18 '12 at 17:01

25

You don't need a service layer. However it helps you to

Decouple 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.

edited Mar 18 '12 at 17:01

Zaki

6,997
6
37
53

answered Mar 09 '12 at 11:52

Johan Sjöberg

47,929
21
130
148

1

The service could also provide shared logic to one or more controllers (e.g. Web controllers and a JSON/WS API) – seanhodges Mar 09 '12 at 11:55
4

You can also easily expose services (service methods) as web services this way... – Matjaz Muhic Mar 09 '12 at 12:04
A non-UI client can directly interact with your service layer which can validate the request. – Blue Sky Jun 19 '12 at 07:09

score 22 · Answer 2 · answered Mar 09 '12 at 11:54

The key is the transactional behavior. If you don't have a service layer, where will you demarcate transactions?

in 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

+1 A service layer in the *domain facade* style is a thin facade over the domain model, not implementing any business logic itself, but indicating the transactions. Much more obvious when using EJB (rather than Spring), where a stateless session bean has container managed transactions. — Raedwald, Mar 10 '12 at 17:11

score 7 · Answer 3 · answered Mar 09 '12 at 11:51

7

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.

answered Mar 09 '12 at 11:51

Donal Fellows

133,037
18
149
215

score 6 · Answer 4 · answered Mar 09 '12 at 11:52

You can save the verbosity by having a BaseService which has all the CRUD operations, delegating to a BaseDAO injected in it.

Apart 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

score 2 · Answer 5 · answered Mar 09 '12 at 11:51

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.

Tell us how you'll do without server layer and with an interface..high level idea, will help me to tell you more.

Do I really need a service layer?

5 Answers5

Linked