Business logic architecture model

Business logic architecture mode (transaction script, table module, activity record, Domain Model)

In fact, the various architecture modes are not shown out of thin air, but the results naturally come when you write code to a certain level of knowledge. When there are many detours, we will take the initiative to think about how to better organize the code and better meet business needs and architecture standards.

Fowler's Patterns of Enterprise Application Architecture is such a book that details common Architecture Patterns in Enterprise-level development. There are four common business logic layers:

Transaction script, table module, activity record, domain model. See the figure below:

 

Note:

1. I drew two layers here: UI and BL. In fact, if it is more extreme, the transaction script CRUD, the table mode XXXManage and the activity record XXXHandler can be merged with the UI Layer.

2. The XXXManage in Table mode and the XXXHandler in activity record are consent words. There are two different expressions.

First, let's look at the transaction script. This is the most process-oriented way of organizing. What operations are required by the upper-layer UI, and the lower-layer writes the corresponding processing method. The advantage of a method that directly operates from the UI to the DB is that it is easy to write, the disadvantage is that the reusability is not enough, and the adaptability to complicated logic is very poor.

Let's look at the table mode and activity records. This is actually two ways to change the tang without changing the change. Compared with the transaction script, the table objects in the database are independent, and a class corresponds to a database table. The standalone method is different: the table mode is a DataTable corresponding to a table, and its CRUD is attached. The activity record is a Model entity class corresponding to a database table, and its CRUD is attached. This method may be convenient for single-Table operations, but it involves complex services. When multiple tables are associated, the corresponding classes of a single table cannot be processed, in most cases, you still need to create a new class named like XXXManage and XXXHandler to deal with such complex logic and multi-Table operations, the method is generally related to the use case of UML. Once the business is complex enough and the project scale is large enough, this method will still lead to insufficient reusability and poor adaptability to complicated logic.

The above three methods share the same point, that is, they are always data-centric. The table structure of the database occupies a very important position in the program logic. The processing of the business logic is always centered around the processing of table data. The Business Code Editor, always understand the database design method. The State part (attribute) of a class is always separated from the behavior part (method), and there is no real object-oriented programming.

Finally, let's look at the domain model. This method is a solution that solves large business volumes and complex logic. This completely abandons the idea of creating a database here, closely analyzes customer needs, extracts business subjects, clarifies interaction methods, and builds flesh-and-blood objects. Finally, save the data or status to the database as required by the customer or program.

There is a comparison of the image: In process-oriented processing, the programmer is God, and you manage everything from page display to business processing to data storage. In the process of object forwarding, you are only the dispatcher. You are only responsible for processing the right business with the right object at the right time.

 

In fact, the various architecture modes are not shown out of thin air, but the results naturally come when you write code to a certain level of knowledge. When there are many detours, we will take the initiative to think about how to better organize the code and better meet business needs and architecture standards.

Fowler's Patterns of Enterprise Application Architecture is such a book that details common Architecture Patterns in Enterprise-level development. There are four common business logic layers:

Transaction script, table module, activity record, domain model. See the figure below:

 

Note:

1. I drew two layers here: UI and BL. In fact, if it is more extreme, the transaction script CRUD, the table mode XXXManage and the activity record XXXHandler can be merged with the UI Layer.

2. The XXXManage in Table mode and the XXXHandler in activity record are consent words. There are two different expressions.

First, let's look at the transaction script. This is the most process-oriented way of organizing. What operations are required by the upper-layer UI, and the lower-layer writes the corresponding processing method. The advantage of a method that directly operates from the UI to the DB is that it is easy to write, the disadvantage is that the reusability is not enough, and the adaptability to complicated logic is very poor.

Let's look at the table mode and activity records. This is actually two ways to change the tang without changing the change. Compared with the transaction script, the table objects in the database are independent, and a class corresponds to a database table. The standalone method is different: the table mode is a DataTable corresponding to a table, and its CRUD is attached. The activity record is a Model entity class corresponding to a database table, and its CRUD is attached. This method may be convenient for single-Table operations, but it involves complex services. When multiple tables are associated, the corresponding classes of a single table cannot be processed, in most cases, you still need to create a new class named like XXXManage and XXXHandler to deal with such complex logic and multi-Table operations, the method is generally related to the use case of UML. Once the business is complex enough and the project scale is large enough, this method will still lead to insufficient reusability and poor adaptability to complicated logic.

The above three methods share the same point, that is, they are always data-centric. The table structure of the database occupies a very important position in the program logic. The processing of the business logic is always centered around the processing of table data. The Business Code Editor, always understand the database design method. The State part (attribute) of a class is always separated from the behavior part (method), and there is no real object-oriented programming.

Finally, let's look at the domain model. This method is a solution that solves large business volumes and complex logic. This completely abandons the idea of creating a database here, closely analyzes customer needs, extracts business subjects, clarifies interaction methods, and builds flesh-and-blood objects. Finally, save the data or status to the database as required by the customer or program.

There is a comparison of the image: In process-oriented processing, the programmer is God, and you manage everything from page display to business processing to data storage. In the process of object forwarding, you are only the dispatcher. You are only responsible for processing the right business with the right object at the right time.