The service layer is the main layer, which connects the presentation layer to the business layer. It exposes some methods through class libraries, Web APIs, or web services used by the presentation layer to perform certain operations and access data. Moreover, it also encapsulates the business logic, and exposes POST, GET , and other HTTP methods to perform certain functionality. There are few advantages of keeping it web-based instead of making it a shared library project.

The following table shows the advantages of both a web-based and a shared library:

The service layer can also contain methods that do not call the business layer, but are helper methods or common methods, which are used by the presentation layer and other consuming parties to the achieve desired functionality. For example, the service layer can contain a method that takes a list of strings as a parameter and returns a CSV (comma separated value) string where this operation does not require any backend database operation.

Securing services is highly recommended when building enterprise applications; keeping the endpoints open leads to counterfeiting of the data from unauthorized access. With ASP.NET, this can easily be achieved by authenticating the user using the ASP.NET security mechanism, protecting resources imperatively through the Authorize attribute or custom policies. The service layer is the primary layer that exposes data to third-party sources. Therefore, logging and transactions should be properly addressed.

There are various approaches to implement the Service layer using the .NET stack. We can use Web API, Service Stack, WCF, and POCOs to create the service layer. However, with .NET Core, we can develop services using Web API, Service Stack, and the POCOs libraries. Whereas WCF can be developed on .NET 4.5 or earlier versions of the .NET framework, proxies can be created using WCF Connected Services.