. Net enterprise-level application architecture design-service layer design

In the domain model, we generally regard the service layer as part of the business layer. Although this practice is very common, it is clear that we have other options. Generally, the service layer defines an interface for the presentation layer to allow the presentation layer to trigger some predefined system operations. As the name shows, the service layer can be seen as a boundary between the end of the presentation layer and the start of the business logic layer. The service layer is used to minimize the coupling between the presentation layer and the business logic layer, the presentation layer does not need to focus on the specific implementation and organization methods in the business logic layer. Therefore, whether you choose any business logic mode (Table module, activity record, or domain model), the system can provide a service.

In fact, the service layer does not perform any specific work. Its function is to organize various business objects. The service layer understands business logic (including workflows, components, and services) Very well and understands Domain Models very well. The service layer not only organizes business components, but also organizes application-specific services, workflows, and any other special components that appear in the business logic layer.

It is controversial to use "service" as the name of the layer between the presentation layer and the business layer. This layer can be implemented through web services or WCF services, or you can choose any other technology. Although the service layer has the word "service", we need to understand it as a word unrelated to technology.

The service layer is located between two logic layers in the system that communicate with each other, so that the two layers can still communicate with each other perfectly while being loosely coupled and beautifully separated from each other.

The core of each user-driven interaction includes two participants: the user interface of the presentation layer and the module implemented by the service layer to respond to user operations. This means that the service layer is not only used to organize business logic, you may need to interact with the persistence layer. All interactions originate from the presentation layer and get responses from the service layer. Based on the received input, the service layer organizes components in the business logic layer, including objects in the service, workflow, and domain model, and calls the data access layer as needed.

Not only does the service layer send database operation requests, but there may be other situations where the business logic layer may also contain some workflows or data access layers required by the Service. The only part of the business logic layer that needs to be completely separated from the database details is the domain model.

Service-oriented

Generally, the service layer is a series of classes that expose logical related methods for other layers (usually the presentation layer) to call. In this abstraction layer, the service layer and the transaction script library are very similar. Without the technical context, the word "service" simply indicates that it can provide services for a layer and send requests to software components on the other layer, the "service layer" indicates a set of services located between two layers for communication. To put it bluntly, more and more people think that "services" are not just code that can process requests. One of the main reasons for this situation is the increasing popularity of service-oriented and service-oriented architecture SOA.

Service-oriented is a business design method consisting of a series of interconnected services. Service-Oriented is not a specific technology, but more like a different way of organizing business operations. In the SOA world, applications are composed and integrated by a series of independent services. This integration process may be similar to the form design process in the previous popular fast application development. However, in SOA applications, the smallest building block is a service, not a component.

The service can fully use its environment and its lifecycle control is more autonomous. Services in the service layer are more suitable than simple classes. It can be said that, if it is not for service implementation, it is not even necessary to become a dedicated service layer independently.

Services can be autonomous, discoverable resources, and fixed interfaces. In addition, a service is usually designed as a stateless component. In general, stateless components have good scalability, and their overall implementation is relatively simple, and can be applied in more different scenarios.

Services in the service layer

In terms of architecture, the service layer applies a general and human-oriented principle in software design with low coupling. Another principle of High Cohesion may be applied. This is achieved by removing the coupling between the user interface and the middle layer through the middle layer.

The emergence of service-oriented architecture enables architects to apply some object-oriented service features to the service layer. The result is that all service layers are composed of and only some services. The root cause of the existence of the service layer as a model is that the concept of service and object-oriented has been gradually applied to internal application logic and external customer operations.

The service layer can be used as a remote layer, but it depends on the project client. The service layer may also be part of the performance layer. In that case, the service layer does not need to be designed as a web service, but can be implemented using components supporting services or some common classes. The focus here is the abstraction provided by the service layer, instead of the specific implementation method. The component that supports the service refers. net Framework supports the mechanism of COM + services. When you need to use additional services provided by COM +, such as real-time activation, Object pool, declarative security, or distributed transactions. For example, when a remote call is required for WCF, it is a good choice for creating services at the service layer. As a service technology, the biggest advantage of WCF is that its configuration capability can easily add some aspect-oriented features to the solution.

The service layer provides a unified contract between the user interface and the middle layer, so the middle layer can focus on implementing application logic. Application logic is part of the business logic. Its design comes directly from the use cases in the requirement. If there is no service layer, you need to call it directly from the presentation layer to the Application Service, which will cause a remote interface with too much granularity, resulting in too much interaction.

The service layer is composed of a series of crude services, which are also called macro services. Macro services are organized and operated according to use cases, and do not contain any domain logic related to core businesses. The presentation layer and service layer do not (or should not) contain business logic. The presentation layer only understands the coarse-grained interfaces provided by the service layer, and the service layer only understands a series of available interactions, pay attention to some specific details, including necessary transactions, resource management, coordination, and data conversion.

Service layer practice

When to use: the service layer should be used in applications with certain complexity. It is just a few weeks of simple and convenient use of web sites, and the service layer cannot bring about some overhead and benefits. SOA does have a relationship with Web Services. SOA is not a web service, but a web service may be a product of the SOA architecture. SOA is a design philosophy, rather than a specific service technology.

Location: whether the service layer is locally or remotely called depends on the current situation. If the service layer can easily move in each physical layer, it will be the best result. In this case, the service technology similar to WCF is the best choice. Upgrading a class in the service layer to a service is not a major action. This operation is implemented through refactoring.

Handling roles and security: If you are very concerned about security, you can check the caller ID for each method in the service layer and reject access from unauthenticated users. If you do not want to repeat the check in each service, you can use a declarative method to ensure security, that is, add security-related features to the service method.

Service-Oriented Architecture

In a distributed system, the focus and needs of the service layer are closely related to services. Service-oriented is a concept that allows you to regard software architecture functions as a collection of business processes. These business processes are encapsulated and exposed into a series of services that can be operated interactively.

The principles of SOA are: clear boundaries, service autonomy, use of contracts, rather than class, and compatibility based on policies.

Clear boundary: the SOA service exposes clear contracts. All interactions with the service must be performed through this public interface. When designing a service, developers should make the interface as simple as possible without affecting future enhancements.

Service autonomy: an autonomous service is a loosely coupled service. Its Design and deployment are independent of other services. However, it can communicate with other services through contract-based messages and policies. The service should be designed to be static and should not be modified after the service is released. To meet this requirement, You must select message-based semantics, because of its flexibility, you can use it as part of a contract.

Use contract, rather than Class: regardless of the technology, data is transmitted based on common and prescribed data formats. Defining a service is to define a service contract and a series of data contracts.

Policy-based compatibility: service accessibility and callability cannot be the reason for a user to call the service. The key is that the user must be able to determine whether a service meets its needs. Services and Data contracts refer to the structure compatibility, that is, whether a specified service can fully meet users' expectations, semantic compatibility should also be exposed through a public and accessible standard policy for external viewing.

Many SOA models are applicable to the service layer, but the anti-pattern is also worth introducing. Two common anti-patterns of SOA are: The crudy and chatty patterns, both of which are related to service contracts. The crudy interface is just a pretty name, and the real enemy is a bad design. Crudy is related to the aggressive mode, which describes a service contract to communicate behavior in a way similar to PRC. In other words, this service exposes a series of fine-grained methods on the presentation layer. The presentation layer must call each other to complete the required operations.

Summary

The service layer is always necessary because it can remove the coupling between the application interface and the middle layer. The only situation that does not consider using the service layer is that you are very sure that the program has only one presentation layer.

Related blogs:

• . Net enterprise-level application architecture design: Contemporary architects and Architectures
• . NET Enterprise Application Architecture Design-UML
  
• Design principles and models for. net enterprise-level application architecture design
• . NET Enterprise Application Architecture Design-Business Layer Design
• . Net enterprise-level application architecture design-service layer design
• . Net enterprise-level application architecture design-data access layer
  
• . Net enterprise-level application architecture design-Presentation Layer Design