1. Transaction scripts
1) Call the database:
Transaction scripts compose all logic into a single process in which the database is invoked directly or only through a simple database store.
2) script processing:
Each transaction has its own transaction script, although common subtasks between transactions can be decomposed into multiple subroutines.
3) Operating mechanism:
A. Transaction scripts should be placed in classes that are independent of other classes that process the presentation layer and the data source layer. There are two ways to organize transaction scripts into classes:
A. Put several transaction scripts in one class, each class organizes related transaction scripts around a topic;
B. Using Command mode, each transaction script corresponds to a class (command)
4) Use time:
Simple scenarios of business logic (while cautiously extracting common subroutines to reduce code redundancy) require domain models when business is complex
When the problem itself is simple, using transaction scripts can speed up development and run faster.
If there are the following requirements:
The database design is as follows:
The Revenue Recognition table refers to the Id of the Control table as the foreign key. According to requirements and database design, transaction script class diagram is designed as follows:
Here, Gateway is the database access register and Recognition Services is the transaction script class. Calculate Revenue Recognition method is used to calculate and save the required entry information (contract number, time, fee amount), and Recognize Revenue is used to query the charged information according to contract number and specified date. The application only needs to call these two methods individually.
2. Domain Model
1) Operation mechanism
The difference between domain model and database model is that domain model is a complex network composed of interconnected fine-grained objects with mixed data and processing process, multi-valued attributes and complex association network, and uses inheritance, strategy and design patterns.
A common problem with domain logic: Domain objects are too bulky and may generate redundant code
Database mapping: Simple domain models can use activity records, while complex domain models need to use data mappers.
Domain models should use fine-grained objects with fine-grained interfaces.
When business rules are complex and changeable, involving verification, calculation and derivation.
Database interaction: preferred data mapper
For the above requirements, the design class diagram is as follows:
As you can see, the policy mode is used here.
3. table module
The table module organizes domain logic with a class corresponding to a table in the database, and uses a single class instance to contain various operating procedures for the data.
The difference between the table module and the domain logic is that if there are multiple orders, the domain model has one object for each order, while the table module only uses one object to process all orders (the table module has no identifier to identify the entity object it represents).
1) Operation mechanism
Strength: Allows you to encapsulate data and behavior, while taking full advantage of relational databases
Use when accessing table data using recordset (table modules depend heavily on data organized in table format)
The design class diagram is as follows:
4. service level
The service layer defines the boundaries of the application and the set of available operations that can be seen from the point of view of the interface client layer. It encapsulates the application’s business logic, transaction control and response coordination in its operation implementation.
1) Operation mechanism
Business Logic Classification: Domain Logic and Application Logic
Two basic implementations:
- Domain Appearance Method:
The service layer is implemented as a thin collection of facades on top of the domain model (the class responsible for implementing the facade does not contain any business logic, and all business logic is implemented by the domain model)
- Operational scripting method:
The service layer consists of a relatively complex set of classes that directly implement application logic, but delegate domain logic to encapsulated domain object classes.
The service layer interface is coarse-grained and can be called remotely if necessary (adding a remote appearance to the service layer or directly enabling the service layer to implement the remote interface)
Service layer advantages:
It defines a common set of application operations that can be used by various customers, and the service layer coordinates the application response in each operation.
When the business logic has multiple customers, or multiple transactional resources in the use case response, the service layer is required