MVC: What is Service Layer

Service Layer

by Randy Stafford

Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.

For a full description see P of EAA page 133

Enterprise applications typically require different kinds of interfaces to the data they store and the logic they implement: data loaders, user interfaces, integration gateways, and others. Despite their different purposes, these interfaces often need common interactions with the application to access and manipulate its data and invoke its business logic. The interactions may be complex, involv-ing transactions across multiple resources and the coordination of several responses to an action. Encoding the logic of the interactions separately in each interface causes a lot of duplication.

A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coor-dinating responses in the implementation of its operations.

Use/Benefit of Service layer:

The service layer approach is appropriate if you have a complex architecture and require different interfaces to your DAO's and data. It's also good to provide course grained methods for clients to call - which call out to multiple DAO's to get data.

Using service layer is a well accepted design pattern in the java community. Yes, you could straightaway use the dao implementation but what if you want to apply some business rules.

Say, you want to perform some checks before allowing a user to login into the system. Where would you put those logics? Also, service layer is the place for transaction demarcation.

It’s generally good to keep your dao layer clean and lean. I suggest you read the article “Don’t repeat the DAO”. If you follow the principles in that article, you won’t be writing any implementation for your daos.

Also, kindly notice that the scope of that blog post was to help beginners in Spring. Spring is so powerful, that you can bend it to suit your needs with powerful concepts like aop etc.

Using a service layer means you get several benefits:

• you get to make a clear distinction between web type activity best done in the controller and generic business logic that is not web-related. You can test service-related business logic separately from controller logic.
• you get to specify transaction behavior so if you have calls to multiple data access objects you can specify that they occur within the same transaction
• you can nest services so that if one has different transactional behavior (requires its own transaction) you can enforce that.
• you can use the postCommit interceptor to do notification stuff like sending emails, so that doesn't junk up the controller.

Scenario

You work as a developer for a financial company that provides stock operations to its clients. The company operates by phone where the clients can talk to an analyst and either buy or sell stocks. The analysts use a .NET windows client application for all related tasks.
The company wants to develop an application where the clients can log on and check their investments and request transactions directly from it. An ASP.NET MVC web application was chosen as the application type and you are responsible for designing it.
Basically all operations, business logic and data access related to the investment transactions are available on the windows client application in a separated assembly from the UI. How can you reuse the code from your ASP.NET MVC application?