Go to. NET Architecture Design-Chapter 3-layered design, preliminary architecture (previous)

Go to. NET Architecture Design-layered design, initial architecture (previous)

This article is not intended to be followed by the previous article. It does not matter. I think the relationship between them is not great. I will make up for it later. Because we have been talking about design and TDD before, and people think it is still a bit "blank", we plan to use another method: First, let's talk about some examples, some ideas are interspersed with stories, and the theoretical things are summarized at the end. Hope everyone can support it!

 

This article describes how to perform logical layering in ASP. NET applications. The first part of this article will begin with the Smart UI anti-pattern and some of its shortcomings, and then explain how to perform logical layering step by step. In the later part, it will also provide an ASP.. NET.

 

 

A stable and easy-to-maintain system must be built on a good foundation. Planning and Designing a good architecture plays a vital role in the success or failure of a project. When we do projects in general, experience tells us that the design of Layer 3 and layer N can basically solve the problem. This is true in many cases. When proposing a design, we often need to consider why we should divide the structure like this, and often bear risks and responsibilities, especially if the project crashes due to the initial design, that's depressing. Therefore, the design proposal must consider the business.

 

Next, let's take a look at the design method of Smart UI.

Smart UI

Think about how we first developed ASP. NET Applications: layout the interface in the page design interface, and then double-click the control to write functional code. In many cases, logical judgment and data access are written in the. cs file on the page. Later, we learned the hierarchy and gradually understood the disadvantages of this method: as a result, the business logic code is scattered and duplicated everywhere, which is not conducive to future changes and maintenance.

 

Despite some of the shortcomings described above, the Smart UI still has its purpose, such as creating a prototype for a project quickly or developing a small project with relatively functions. There is another question: how can we successfully develop small projects using the Smart UI method and gradually become more complicated? A lot of problems will arise. As Flower mentioned in the architecture model book, we try to use a domain model to organize the business logic of a project. Although the logic is not complex at the beginning or the benefits of this method cannot be seen, once the project changes, the benefits are obvious. In prototype development, try not to use Smart UI.

 

In fact, the biggest problem with Smart UI is: unclear responsibilities-writing all the things together.

To compare with the content described later, I wrote an example. Many of my friends are familiar with this Smart UI development method. you can skip the example below.

 

Here we useProduct Management SystemFor example, all product information is displayed. The example is implemented using ASP. NET. The steps are as follows:

1. Create an ASP. NET project for AgileSharp. Chapter3.Antipattern, as shown in:

 

2. Select the "App_Data" folder and add the Database "OrderManagement. mdf", as shown in:

 

 

 

 

3. Right-click the newly added database file and open it. Add a new table as follows:

 

 

The ProductId is set to automatic.

Save as the Products table.

 

4. Add some test data.

5. Select the Products table and drag the table to the Default. aspx page. Then, a GridView and SqlDataSource are automatically added to the page.

 

The interface is like:

 

6. I will add two additional columns to display the discount information and inventory information.

 

7. Then, we encode it after Default. aspx. cs:

 

Protected void gvProduct_RowDataBound (object sender, GridViewRowEventArgs e)
{
If (e. Row. RowType = DataControlRowType. DataRow)
{
IntproductId = int. Parse (System. Data. DataRowView) e. Row. DataItem)
["ProductId"]. ToString ());

Decimal price = decimal. Parse (System. Data. DataRowView) e. Row. DataItem)
["Price"]. ToString ());

Label lblDiscount = (Label) e. Row. FindControl ("lblDiscount ");

LblDiscount. Text = DisplayDiscount
(ApplyDiscountsStrategy (productId, price ));

}
}

AboveGridView1_RowDataBoundThe method is called when each row in the GridView is created. This method gets the recommended Retail Price RRP (Recommend Retail Price) for each product, then calls the DisplayDiscount and DisplaySavings methods to get discounts and inventory, and then updates the UI display.

In the above Code, the logic for calculating discount and inventory is written in the UI, and the data access code is also written in the UI. This means that if we want to display product information on different pages, these logics must be rewritten over and over again. If we are adding some new functions, the code at the end of the page will start to be modified to start sewing and completing.

 

The solution to Smart UI isDivision of dutiesI think everyone knows the "single responsibility principle". This principle applies not only to classes and methods, but also to project hierarchy. The main purpose of layering is to place inaccessible functions in their respective locations. This clear division of duties also separates the change points.

The following figure shows a typical enterprise-level ASP. NET project hierarchy:

 

Let's take a look at how to design this function based on our general layered experience:

Next, we will try again to redesign the previously mentioned order management system to adapt its functions to new needs (in many cases, it is basically impossible to redesign, therefore, you need to consider it clearly when starting the design. Here, the re-design is only taken into account from the perspective of examples ):

(1) users can access the system through web pages or PC Desktop programs.

(2) The order management system must provide services to other systems (such as the financial system.

(3) Some order processing procedures and related business processing are required in other systems.

(4) There are more requirements to be confirmed.

 

 

Note: You can see at a glance that the names of these class libraries reflect

Some concepts of DDD, but it does not mean that the development method is DDD if these concepts are used in the development of a project.

 

Here I will first mention the name of the above class library: although I will talk about the concepts of DDD and some architecture patterns in a later article, I will give it to you here, the purpose is to give you a better understanding of this example.

In DDD, we have always advocated the business model, which we often call the business class. For example, the Product in the previous example only focuses on its own business logic, regardless of how to obtain and save data, these data operations are completely handed over to another object for execution, that is, Repository, so that the PI (Persistence Ignore) mentioned in DDD is reached ). So in the above example, ASPPatterns. chap3.Layered. the Model represents a business Model that is referenced by Repository because the Repository is responsible for persisting the data of the Model to the storage device, regardless of the Model.

 

Before talking about it, we should first unify the concept of Service.

Sometimes, in the course of designing a class, some behaviors are not suitable for any class. If you place these behaviors in a class that does not really own it, you can only confuse the responsibilities of a class. To place these actions in a place, we often place these actions in a class called a service.

 

A service class is generally stateless and can be implemented simply as an operation interface.

In DDD, Service is also used to provide a Service. Many people have seen that the class hierarchy of DDD is like this: Repository --- Model --- Service --- Presentation (including this example), so they all think that the Service can only appear on the previous layer of the Model, if you see a hierarchy like Repository -- Service --- Model --- Service --- Presentation, what do you think. If you are confused by these so-called structures, it means that the understanding of DDD is only in the form.ServiceIs to provide external functional interfaces, and our common Web ServiceSimilar concepts, such as Web ServiceIt provides some functions to external systems.

Let's take a look at the following figure:

 

 

Sometimes we need to add a Service layer on the Model layer. The main reason is to implement a coarse-grained API, which is often related to the User Case of the system. For example, if you want to process a user Order in a system use case, the Customer, Product, Order, and other classes may be involved. Of course, if we call these classes to complete this task together, but this exposes the complex relationships between these classes to the caller, and if the process changes, the caller's code needs to be changed. If the method of processing is put in any of the above classes, the Service function here is similar to the Fa C ade appearance mode in the design mode. In this way, a simple API is provided to the outside world to provide order processing services to the outside world!

 

Therefore, in DDD, the business layer is generally divided into two logic layers: Model (Providing fine-grained business logic processing and facilitating reuse), Service (providing business processing processes, provides coarse-grained methods for external calls ).

 

However, the Service layer on the Model layer is only a re-encapsulation of CRUD. One possible reason is that the business is not very complicated. In this case, the Service layer can be removed, however, the Service layer is retained because the logic may be more complex in the future.

 

In fact, the Service on Repository is also the same concept. For example, the function of sending email notification to users. For example, the upper-level Service in the middle can call the Service at the business layer and infrastructure layer to accomplish one thing together.

 

Let's talk about this part in the previous article. I will use an example in the next article. The amount of code is still a little bit! Stay tuned!

If you are interested, let's talk about it in the next article!