Service Layer vs Business Layer in architecting web applications?

I know this might sound silly but I am finding it hard to understand the need of a service layer and its differences with business layer.

So, we are using asp.net mvc 2 and have Data Access layer which does all the querying with the database and then we have the Business Layer which has the business logic and validations needed to be done. Finally we have the Presentation Layer which basically has all the views. In addition we also have some helpers,DTOs and viewmodel classes in different folders as a part of our libraries. But I have tried to read about architecture and it seems that service layer is an important part of an architecture.

All I understand is that a service layer is something that calls all the functions. But I can't really see the need of Service layer in our application ? Or it might be already there and I can't see it... Can anyone explain with an example how a service layer is important ? How it is different from a business layer because from what I have read seem pretty similar? If its in the first needed at all ? All we trying to do is architect our application in the best possible way what are your thoughts and experience on it ?

Solution 1:

It is all about decoupling your app into self contained pieces, each one defined by the requirement to do one job really well.

This allows you to apply specialised design patterns and best practices to each component.

For example, the business layer's job is to implement the business logic. Full stop. Exposing an API designed to be consumed by the presentation layer is not its "concern".

This role of the go between is best performed by a service layer. Factoring out this specialised layer allows you to apply much more specialised patterns to each individual component.

There is no need to do design things this way, but the accumulated experience of the community indicates that it results in an application that is much easier to develop and maintain because you know exactly what each component is expected to do, even before you start coding the app.

Each layer should do one job really well. The role of go between that the service layer performs is one such well defined job and that is the reason for its existence: it is a unit of complexity that is designed in the same way over and over again, rather than having to reinvent the wheel each time, to mangle this role with the business logic where it does not belong. Think of the service layer as a mapping component. It is external to the business logic and does not belong in its classes, or in the controllers either.

Also, as a result of being factored out of the business logic, you get simpler business objects that are easier to use by other applications and services that the "business" consumes.

ASP.NET MVC is nothing if not a platform to enable you to write your apps as specialised components.

As a result of this increasing understanding of how to specialise components, programs are evolving from a primordial bowl of soup and spaghetti into something different and strange. The complexity they can address, whilst still using simple structures, is increasing. Evolution is getting going. If life is anything to go by, this has to be good, so keep the ball rolling.

Solution 2:

You might find the term Architecture Astronaut interesting.

The point is, don't get caught up in all of these "layers" that people bandy about. Every time you had another layer to the application, there has to be a purpose in it.

For example, some people successfully combine the concepts of a Data Access and Business Logic layer into one. It's not right for every solution, but it works out perfectly for a lot of them. Some people might even combine Presentation with Business... which is a major no no in a lot of circles but, again, may be perfect for the need in question.

Basically, the problem you are solving should dictate the structure of the application. If other applications need to integrate with yours, then a Service Layer may need to be added. This might take the form of simple web forms which others can post data to or it might go further to be full on web services. There might even be situations where you want the service layer to be the primary go to location for multiple presentations.

You can get as complicated as you want, but a good rule of thumb is to keep it simple until the complications become necessary.

Solution 3:

In some designs, the service layer is not used by the presentation layer.

The service layer is called by other applications that want to use the business and data access layers in the application.

In a way, the service layer is another front-end separate from the presentation layer.

See the architectural diagram here. The users access the application through the presentation layer. And the external systems access the application through the services layer. The presentation layer and the services layer talk to the application facade in the business layer.

As an example of what those other "external systems" might be, web services and WCF services call the service layer. Some other web application could call this application's service layer in a web service call. This would be one way to ensure that both apps are applying the same business logic, and that any changes made to the business logic are reflected in both of the apps.

As Chris Lively points out, one shouldn't get carried away with creating layers. I would recommend only creating the layers that would be useful in your application. In my experience, the need for a service layer is not frequent, but the need for a business layer is very frequent.