. NET application architecture design-coding of table module mode and transaction Script Mode

. NET application architecture design-coding of table module mode and transaction Script Mode

Reading directory:

1. Background introduction 2. A brief introduction to the table module mode and transaction Script Mode 3. Correct Coding of the table module mode and transaction Script Mode 4. Summary 1. Background introduction

To design the system architecture correctly, you must be able to understand the intention of each architecture model correctly, rather than the eyebrows. What is the current phenomenon? On the surface, the project structure is quite good and the layers are quite reasonable. In fact, there are also several layers of design methods for the business system, however, the design of the logical architecture of many projects is not ideal, and many concepts are not well understood. Of course, everyone may have different technical pursuits. No matter whether you pursue or not, we still need to work in the right direction.

Many people, including myself, have been writing process-style code for many years. The layer is just a decoration for me in the past, the most typical problem is that we always mix the table module mode with the transaction Script Mode. What does this mean, that is to say, we will use some code generators to generate the business layer and data layer in the three-tier architecture based on the tables in the database. Some good code generators can also help you to generate some views in the UI Layer, it is really powerful. In some cases, this is the most suitable process.

But now the system is no longer like that. The important point is that the business is complicated. If we write code in a confused way, it will only become the technical debt of you or the team.

2. A brief introduction to the table module mode and transaction Script Mode

Let's take a brief look at what the so-called "Table module mode" and "transaction Script Mode" look like, the most important thing is that you may know the architecture style of the business layer you are currently using. Emphasize that "Table module mode" and "transaction Script Mode" are both the architecture modes of the business layer.

Table module mode:

Simply put, each table in your database corresponds to an object definition in the Business Layer. If you have a Product table, you have a Product in the Business Layer. cs file. Of course, this is not absolute. You can also define the view type in the database, such as OrderProduct. cs. Then the logic processed in each class is related to this table. Your code in Product. cs should not contain the Code in Order. cs. Currently, most projects are written with procedural code, that is, the Script Mode of things. This will inevitably write code of other types to this class.

Script Mode:

The transaction script mode is a procedural code, but its indicator is that each code segment completes a business unit independently, rather than process code everywhere. The transaction Script Mode emphasizes the uniformity of logic.

When writing code in this mode, you should not simply use the table name in the database to define the business class, because you use the transaction Script Mode, you need to plan which business concepts are included in your business layer from the business perspective, and then use this business concept to name your class. For example: UserOrder and UserOrder, similar to this definition. Of course, this is just a hypothesis. You can just design the business layer by running the database script, in this way, at least you will not use fine-grained types, even if the next iteration is refactored.

3. Correct Coding of the table module mode and transaction Script Mode

The focus of this article is this section. Let's take a look at how to write the code for these two modes.

It seems a little rude to say how to write code. In fact, most of the code we write is correct. However, if we place some code slightly differently.

Let's look at a small example. The example is very simple. There are two types of Order and Product to complete general business logic processing. We can see how to use them in different modes.

Code of the current transaction Script Mode:

Namespace Business {public class Order {[Serializable] public class OrderField {public string OId {get; set;} [NonSerialized] public List
 
  
Products {get; set ;}} public OrderField Field {get; set ;} public void AddOrder (OrderField orderField) {var sendMQOrders = new List
  
   
(); // The orderField set of qualified product IDs. products. forEach (product => {if (product. price <= 20) // does not meet the condition return; sendMQOrders. add (product. PId); // meets the condition}); MqHelper. sendOrder (orderField, sendMQOrders); // send the order data entity to the queue }}}
  
 

There is an Order method in the Order service class. This method involves some simple business logic processing and determines whether the price of the product to be added is more than 20 RMB. Finally, use the filtered product ID as the valid product for this order.

This is the code style we are currently using. There are two problems here: first, class naming. The concept of Order is too big and not refined, obviously, it is not designed according to the transaction script mode, but by the table module mode. If I design it based on the transaction Script Mode, do I like to define big concepts? Yes, but the subtype of the Product type is clearly used in the Order definition, so there are two independent business scopes here, the normal understanding must be based on the table module mode. Second: if it is designed according to the table module mode, because the naming of this object is obviously this mode, but read the code carefully and find that the responsibilities are still a bit unclear. In Order. in the AddOrder (OrderField orderField) method, the logic of Product is in if (product. price <= 20). Of course, the business logic is relatively simple. If the business is complicated, a large amount of code will appear in the Order class, in the end, we will find that we have no idea which mode is used to design the business architecture.

We have two methods. The first one is to change it to the transaction Script Mode to make the class name and design generalized. That is to say, do not define the table name in the database that is so obvious, do not clearly distinguish between Order and Product. The second approach is to change it to the table module mode to completely clear the business logic of each type and convert if (product. price <= 20) is extracted to the Product business class, and then the application controller processes the logic first and then calls Order. the AddOrder (OrderField orderField) method is only used to process the logic related to the current type. The reference is that once you find that there are other types in your code, at this point, you should tell yourself that it is possible that you need to restructure your responsibilities.

Two methods to move this logic:

1 :( enclose if (product. Price <= 20) in the Price attribute)

Namespace Business {public class Order {[Serializable] public class OrderField {public string OId {get; set;} [NonSerialized] public List
 
  
Products {get; set ;}} public OrderField Field {get; set ;} public void AddOrder (OrderField orderField) {var sendMQOrders = new List
  
   
(); // The orderField set of qualified product IDs. products. forEach (product => {if (product. price. isValid ()/* execute price judgment */) return; sendMQOrders. add (product. PId); // meets the condition}); MqHelper. sendOrder (orderField, sendMQOrders); // send the order data entity to the queue }}}
  
 

The problem with this method is that the price of the product has not been controlled by the order, which depends on the specific business needs. I am just a hypothesis.

2: completely independent method for filtering invalid Products

Namespace Business {public class OrderApplicationController {public void SubmitOrder (Order. orderField field) {field. products = new Product (). filterProduct (field. products); // filter new Order () first (). addOrder (field); // Add }}}

We first call the Business Method in the Product to filter out invalid items, and then add orders, so that we can place our respective responsibilities in our own place.

4. Summary

That sentence is just a little bit of comprehension in my learning process. I hope it will be useful to you. Thank you.

Author: Wang qingpei

Source:Http://blog.csdn.net/wangqingpei557

The copyright of this article is shared by the author and CSDN. You are welcome to repost it. However, you must retain this statement without the author's consent and provide the original article connection clearly on the article page. Otherwise, you will be entitled to pursue legal liability.