Business Logic organization in a database-centric system

 

Author: Baidu youah lab
Source: http://www.youalab.com /? P = 458

Preface

I believe many people have similar experiences: As the business grows and the system becomes more and more complex, we will all feel that our code is getting ugly and repetitive code is getting more and more difficult to maintain. Well, this is indeed a problem, but is it possible to solve it? To be honest, it is really difficult, but it is not completely impossible, or there is a possibility of improvement. I have recently studied and considered this issue and summarized it in a purely theoretical manner. I hope it will be helpful to those who are interested in this aspect.

Many application-oriented systems are data-centric. In these systems, data is stored in databases. business logic Code organizes logic based on the data stored in databases; take the system of purchasing commodities as an example. Commodity data, transaction data and user data are the core data in the system, and most business code is to flip the data as needed. This is very consistent with the definition of the program: program = Data + behavior; here, data is data in the database, and behavior corresponds to the business logic.

For the system we have built, we naturally want good scalability and maintainability. This is a very challenging thing, especially for large-scale applications; whether it is true or not depends on the logical organization. This article introduces three typical business logic Organization Methods in database-centric applications.

Logical organization mode transaction Script Mode

Transactions here are different from database term transactions. Transactions here refer to one business interaction.

In an application system, most business logic can be seen as a collection of sub-tasks. For example, when a user buys a product, it can be roughly divided into several steps:

1. First, query the database based on the product information to see if any salable product exists;
2. If yes, add a purchase record for the user's purchased items;
3. Then reduce the number of items;
4. Other things, such as sending emails to users.

When code is organized using a transaction script, there is no hierarchy in the business logic organization. When a specific business is implemented, a series of transaction calls are performed from the beginning to the end based on the business needs; for example, if you want to purchase a product, first query the quantity of the product in the database, and then determine whether it is sufficient. If it is sufficient, add the records of the user's purchased product, and then operate the database to reduce the product. This method has an obvious feature. A transaction script can be used as a use case or function. This method has obvious advantages, which are simple, intuitive, easy to learn, and easy to use. It is easy to understand because it is similar to the intuitive way of thinking. In practice, many systems are implemented in this way, especially those rapid development systems. However, the low degree of abstraction may easily lead to repeated code, high coupling with other systems, and difficult maintenance, especially for complex systems. For example, after the desktop version is provided for purchasing products, the mobile version also needs to be implemented. Because the mobile version and the desktop version are two different use cases, if you use the transaction script to organize code, it is natural that similar code appears in different places. Obviously, optimization is encapsulated into functions, but the modularization of function encapsulation is low. In the case of complicated business, it is a challenge to effectively manage and maintain the business logic.

This method is suitable for relatively simple business logic environments. In reality, many businesses are simple. This method can work well on the premise of efficient development and operation; it is also very suitable for quick development environments. However, when the business logic is complex and there is a long maintenance period or a large amount of maintenance after the launch, it may not be a good way.

Table module Mode

In the transaction script mode, it is easy to cause:

1. The same or similar code is repeated;
2. The related logic is distributed in multiple places. The previous problem can be improved by encapsulating the same or similar logic into a function. The second problem can be controlled through the process or specification. However, it is still a challenge to effectively manage and maintain the business logic in complex business situations because of the lack of an effective coding mechanism to control such problems.

The table module organizer can provide a relatively good solution. The general idea is to organize the logic related to one or more database tables (or views) into one class, organize the logic related to this table into the method of this class. Taking the purchased item as an example, it may be a separate method to check whether the item is sufficient. Modifying the number of items is a separate method. purchasing a product is a method, the preceding two methods are organized. Once this logic is available, you only need to use the logic of the purchased product to directly call the method for purchasing the product. In addition to the purchased product, other product-related logics are organized in this class, avoiding distribution of product-related logic to multiple places.

In addition to providing a code organization method, this organization method also has some other advantages: it can be directly tested without the need for database tables, and it is also convenient for piling testing; it is easy to use with database operation APIs provided by many languages. The results returned by many database operation APIs are city records, especially those provided by Microsoft ,. the dataset provided by. NET is even more powerful. In fact, the development platform provided by Microsoft advocates organizing logic in the form of table modules and provides various convenient development tools and APIs. It balances the effectiveness and complexity of Management Code, it is more complex than the previous transaction script method, and much simpler than the domain model method mentioned later.

Domain Model

The organization of code in the domain model mode is the OO programming idea. It is highly scalable and maintainability to visualize the domain logic to achieve complicated business logic. The table module organization method balances the effectiveness and complexity of Management Code, but the abstract mechanism provided by the table module is limited. It is not powerful in managing complicated business logic. For example, the purchase logic may be different for different types of products. In this case, the power of coding is better. In this example, the behavior during purchase may be different. Using the polymorphism mechanism, the caller may be transparent.

The difference between a domain model and a table model is that the intensity of OO is different. A table model is organized in units of tables, and a domain model may be organized in units of records in tables, therefore, in the Code, a table has only one class instance, while the domain model has an object for a record.

The advantage of this model is that it is convenient for effective management of complexity and scalability. It is suitable for complex business logic and systems with long maintenance periods. However, its disadvantages are also clear: OO modeling is complex and the development cycle is longer. Learning costs are high, especially for new teams. Similarly, if the Code Organization is poor, similar problems may occur in other ways, such as repeated code.

Summary

The three different logical organization modes have their own characteristics. They are suitable for different occasions and can be selected based on the actual situation. Generally, for simple applications that require fast development and short maintenance cycle, you can consider the transaction Script Mode; when the business logic is complex and the maintenance cycle is long, the domain model can be considered when the developer's skills are met. In the two intermediate situations, the table module mode can be considered, especially on Microsoft's platform. In reality, due to the complexity of the actual business, it is often not enough to organize in a single way. It may be used in combination in several ways. For example, the core business is organized by domain object, and then the variable application business is organized by transaction.

 

 

Source: http://www.youalab.com /? P = 458