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

In fact, the various architecture models are not shown out of thin air, but you writeCodeThe result that appears naturally when you reach 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 and has poor reusability. It is extremely adaptable to complex logic.

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 UML case. 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, inProgramThe logic occupies a very important position. The processing of business logic is always centered around processing table data. The business code writers always need to 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.

 

ReferenceArticle:

System Architect-Basic to enterprise application architecture-business logic layer

ASP. NET architecture design-Chapter 4-layered architecture at the Business Layer

Nine non-object-oriented objects

Thoughts on activerecord, domain model, and ibatis

Dao-persistent layer-domain object-Anemia Model

Activerecord Model