. NET application Architecture design-code Writing of table module pattern and transaction script pattern

Read the catalogue:

• 1. Background information
• 2. Simple Introduction table module mode, transaction script mode
• 3. Correctly write table module mode, transaction script mode The Code
• 4. Summary

1. Background information

To properly design the system architecture, you must be able to correctly understand the intent of each architectural pattern, not the beard and eyebrows cluth. Now there is a phenomenon, the structure of the project from the surface is very good, the layer is very reasonable, in fact, the business system is also a few layers of design methods, but now many of the project's logical architecture design is not ideal, there are many concepts we are not very understanding, of course, perhaps everyone on the pursuit of technology is different. Whether you pursue it or not, the truth is we have to go in the right direction.

A lot of people, including myself, have written a lot of years of process code, the layer is a decoration for me, the most typical problem is that we always use the Table module mode and the thing script pattern mixed together, what meaning, That means we'll use some code generators to generate the business and data layers in a three-tier architecture based on the tables in the database, and some of the better code generators can also help you generate some of the views in the UI layer, which is really powerful, and in some cases it's the most appropriate process.

But now the system is no longer the case, one of the important thing is that the business is complex, if we are still writing code, and finally will only become you or the team's technical debt.

2. Simple Introduction table module mode, transaction script mode

Let's take a quick look at what the so-called "table module mode", "Transactional scripting mode" really looks like, and the key is that you probably know what the business Layer architecture style you are using today, emphasizing that "table module mode" and "thing Scripting Mode" are the architectural patterns of the business layer. .

Table Module Mode:

The simple thing is that each table in your database corresponds to an object definition in the business layer, and if you have a product table, you There is a Product.cs file in the layer, which of course is not absolute, and you can also define a type of view in the library, such as OrderProduct.cs, which is also possible. Then the logic that is handled in each class is related to this table, and your code in Product.cs does not include the code in the Order.cs. At the moment, because most of the projects are now written using procedural code, which is the thing scripting pattern, it's hard to write code from other types into this class.

Things script mode:

A transactional script pattern is a procedural code, except that its indicator is that each piece of code completes a business unit independently, rather than the process code everywhere, and the thing script pattern emphasizes the unity of logic.

When using this pattern to write code, you do not simply use the table name in the database to define the business class, because you are using transactional scripting mode, you need to stand in the business perspective to plan what business concepts are likely to be included in your business layer, and then use this business concept to name your class. For example: Userorder,userorder, like this definition, of course, this is just a hypothesis, you do not stand in the database script to design the business layer on the line, so you can at least not use a very fine-grained type, even if the next iteration of the refactoring is possible.

3. Correct code for table module mode, transaction script mode

The focus of this article is on this section, and we'll look at how the code for both of these patterns should be written.

It seems a bit impolite to say how code is written, but most of our code is written correctly, but if we take some of the code a little bit, it will be significantly different.

let's look at a small example, the example is simple, there are two types of order, Product, to complete the general business logic processing, we look at how to use different patterns .

Now the code for the transaction script pattern:

namespace business{public    class Order    {        [Serializable] public        class OrderField        {            public String OId {get; set;}             [NonSerialized]            Public list<product.productfield> Products {get; set;}        }         Public OrderField Field {get; set;}         public void AddOrder (OrderField orderfield)        {            var sendmqorders = new list<string> ();//Qualified Product ID collection             OrderField.Products.ForEach (Product =            {                if (product. Price <= 20)//not meet the conditional                    return;                 Sendmqorders.add (product. PID);//Meet the Conditions            });             Mqhelper.sendorder (OrderField, sendmqorders);//Send order data entity to queue}}}    

There is a method for adding order in the order business class, in which a simple business logic process is used to determine whether the price of the item to be added is greater than 20 dollars. Finally, use the filtered product ID as a valid product for this order.

This is the code style we are currently using, here are two questions, the first: class naming, the concept of order is too large, not to be refined, obviously not according to the transaction script pattern to design, but in accordance with the table module way to partition, and if I even if you are in accordance with the object script pattern to design, I just like to define a big concept, isn't that right? Yes, but the sub-types under the product type are explicitly used in the definition of order, which means that there are two separate business scopes, and the normal understanding must be designed according to the table module pattern. Second: If it is designed according to the table module mode, because the naming of this object is obviously this pattern, but read the code to find the responsibility is still a little unclear, in the Order.addorder (OrderField OrderField) method, There is the product logic inside if (product. Price <=), of course, here is the business logic is relatively simple case, if the business is more complex, there will be a lot of code in the Order class, in the end, we will find that we have no way of the business architecture is the use of the model to design.

We have two practices, the first approach is to change it to a transactional scripting pattern, so that the class naming and design generalization, that is, do not define the obvious database table names, do not clearly distinguish between order and product two responsibilities. The second approach is to change it into a table module pattern, fully clarify the business logic in each type, and the if (product. Price <= 20) is extracted into the product business class and then processed in the application controller after processing this logic in the call Order.addorder (OrderField OrderField) method, which only makes the logic related to the current type, The reference is that once you find that there are other types of code in your writing, you should tell yourself that it is possible that this place needs to be refactored.

Two ways to move this logic:

1: (The 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<product.productfield> Products {get; set;}        }         Public OrderField Field {get; set;}         public void AddOrder (OrderField orderfield)        {            var sendmqorders = new list<string> ();//Qualified Product ID collection             OrderField.Products.ForEach (Product =            {                if (product. Price.isvalid ()/* Execute price Judgment */) return;                 Sendmqorders.add (product. PID);//Meet the Conditions            });             Mqhelper.sendorder (OrderField, sendmqorders);//Send order data entity to queue}}}    

The problem with this method is that the price of the commodity is not receiving control of the order, which depends on the specific business needs, I am just a hypothesis.

2: Completely independent method of 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);//In addition}}}    

We first call the business method in product to filter the invalid items, and then we make the order additions so that we can put our respective responsibilities in our own place.

4. Summary

Or that sentence, this is just my learning process a little bit of understanding, to give you a reference to the information, hope to you useful, thank you.

King Qingyue Culture

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

This article is copyrighted by the author and Csdn, welcome reprint, but without the consent of the author must retain this paragraph, and in the article page obvious location to the original link, otherwise reserves the right to pursue legal responsibility.

. NET application Architecture design-code Writing of table module pattern and transaction script pattern