Shulou(Shulou.com)06/03 Report--

This article focuses on "how to understand the .NET logical hierarchical architecture", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to understand the .NET logical hierarchical architecture.

one。 Basic knowledge preparation:

1. Principles of the layer:

(1) each layer is called by the upper layer in the form of interface.

(2) the upper layer can only call the lower layer.

(3) dependency can be divided into two types: loose interaction and strict interaction.

two。 Business logic classification:

(1) Application logic.

(2) domain logic.

3. Layer adopted:

(1) presentation layer (user interface layer): domain independent.

(2) Service layer (application layer): application logic.

(3) Business logic layer (domain layer): domain logic.

(4) sharing layer: provide common code.

(5) implementation layer: provides interface implementation.

4. Agreement:

(1) Domain model is used by default in domain layer.

(2) the data access layer needs to refer to the domain model by default.

two。 Hierarchical architecture

The three basic layers of hierarchical architecture are presentation layer, business logic layer and data access layer. If the business logic layer is divided into service layer and domain layer according to the classification of business logic, the three layers are expanded into four layers: presentation layer, service layer, domain layer and data access layer. The data access layer must generally understand the domain model, which creates two-way dependencies between tiers, and we usually have the following two solutions:

1. Place the domain model on the sharing layer:

Evaluation: PetShop adopts this model, but it has many disadvantages: the business logic layer does not live up to its name, the domain model is actually a data model, maintains inter-layer dependence, introduces more dependence, obvious data-driven ideas, and does not take the domain as the core.

two。 Define the data access interface at the business logic layer:

Evaluation: NopCommerce adopts this model, even if it adopts the separation of service layer and the naming of resource base, but NopCommerce is not DDD hierarchical architecture, but only adopts the common three-tier architecture of domain model and interface separation principle. Cons: apart from data real estate, no other specific technical dependencies are separated from the business logic layer.

III. DDD layering

DDD layer clearly divides the business logic layer into application layer (service layer) and domain layer. At the same time, the specific technical implementation of data access and other interfaces are unified into the infrastructure layer.

1. Original DDD layering:

Evaluation: the advantage is that the specific technology implementation is separated from the domain, and the reuse value of the infrastructure layer is increased. The disadvantage is that the concept of sharing and implementation is not used to subdivide the infrastructure layer, resulting in reverse dependencies in the implementation of warehousing in the infrastructure layer, although there is no impact in a single project solution (only formal dependencies at the namespace level). However, in .NET multi-project solutions, warehousing can only be implemented independently into a similar data access layer through interface separation.

two。 Improved DDD layering:

Evaluation: the infrastructure layer has the characteristics of both sharing layer and implementation layer. The advantage is that it finally achieves the formal domain as the core and solves the embarrassment that the warehouse can not reference the domain model in the infrastructure layer, but the disadvantage is that there is no distinction between the concept of sharing and implementation.

3. The latest DDD tiering:

Evaluation: the advantage is that this is really domain-centric, and it is no longer necessary for the infrastructure layer to reference the domain layer and adapt again in the service layer. Use the principle of dependency inversion to completely invert the dependence of each layer on specific technology. The disadvantage is that the dependency inversion application goes too far, and there is no problem in a single project solution, but it can lead to a two-way dependency in the form of a namespace in a .NET multi-project solution. As the implementation layer, the infrastructure layer basically has no value of reuse. A better way is to change the location of the user interface layer and the infrastructure layer in the figure.

You can consider adding appropriate sharing layers to the above figure as needed.

four。 Architectural Trends:

(1) take business logic as the core and pay more attention to business logic.

(2) divide the specific dependence of the business logic layer into a level of unified management.

(3) pay more attention to reducing dependencies within solutions rather than code reuse between solutions.

(4) the separation of sharing layer and implementation layer will be reflected more and more. For example, the onion architecture.

At this point, I believe you have a deeper understanding of "how to understand the .NET logical hierarchical architecture". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.