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 ?

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.

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.

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.

The Service Layer is usually constructed in terms of discrete operations that have to be supported for a client.

For example, a Service Layer may expose Creating an Account. Whereas the Business Layer may consist of validating the parameters needed in creating an account, constructing data objects to be persisted, etc.

Oftentimes, the Service Layer uses a procedural or Transaction Script style code to orchestrate the business and/or logic layers.

Knowing this, you may realize that your Business Layer really is a Service Layer as well. At some point, the point from which you're asking this question being one such point, the distinction is mostly semantic.

From my perspective a service layer allows you to isolate your presentation layer from your business layer, in the same way the business and data access layer isolates you from how you persist the data.

Inside your business layer you'd put things that are pivotal to your 'business'. A contrived (and probably poorly conceived example) would be to have that be the place where say discounting prices on a product occur.

The service layer allows you to further seperate the interface from the business. Or even swap out other business layers depending on the changing scenarios of the business.

Not every application needs one though (a lot of variables go into that determination), too much architecture can introduce complexities your team may not need.

Have a look to what Randy Stafford says about Service Layer in the "P of EAA" Book http://martinfowler.com/eaaCatalog/serviceLayer.html

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

Simple. To expose your business logic to a client, use a service layer. Ask yourself:

When changing the business logic, should the service layer change? If the answer is "not always" then a service layer is needed.

I know this thread is old, but one useful thing I've done in the Service layer is to handle transactions (Business Layer shouldn't need to know how to handle rollbacks, ordering of operations, etc.).

Another thing I've done is used it to translate between domain entities and DTOs. The Business layer deals with the domain model, but I've passed the data back to the presentation layer in the form of DTOs (in some cases it wasn't practical to expose the whole domain model to the presentation layer for various reasons), so the service layer handles this mapping.

Ultimately, I see the business layer as more fine grained, whereas the Service layer can be more coarse in that it could call multiple operations in the BLL, and order calls within one service call.

Yes, and I would also note on that the service layer is a good place for authentication, both role based and user based.