Encapsulation design of the business logic layer

In system development, the classic layer-3 or layer-4 architecture is usually used. The data model layer uses ORM tools to generate model code and implement the CRUD Method for database operations. The business layer at the upper layer is simply encapsulated for calling at the interface layer. However, because the model layer corresponds to a single table in the database, and many data models are related to the linking and upper-and lower-level relations, if you only encapsulate the business layer for value passing and layering, the following problems may occur during development and maintenance:

1. When adding and modifying data on the upper-layer interface, you need to maintain the association and upper-and lower-level relationship between data;

2. When calling delete or other operations on the upper-layer interface, you need to process cascading deletion data;

3. When operating a sub-menu of a data on the upper-layer interface, it is usually re-obtained to increase the number of database accesses;

4. When the upper-layer interface controls the operation menu based on the selected data, it is necessary to re-load the permission information for complicated permission judgment;

5. logs are usually required for data modification operations, and the interface layer has a large amount of log record code;

6. A large amount of code is required for sorting and removing (moving) operations.

 

I have personally experienced the above problems in C/S architecture application development. I wonder if it is universal. Therefore, we hope that the business layer can encapsulate the "additional" information related to the above issues and achieve the following results:

1. The ability to automatically determine whether the operation is supported between two data points when moving out (in;

2. In common sorting, business objects can be sorted by themselves;

3. When a user selects a data, the user's permissions can be identified to control the interface menu;

4. encapsulate log operations into a unified interface, and automatically record data at the business layer when data modification occurs. The upper layer does not know log records;

5. Abstract all types of data in the system into a unified resource interface.

According to the above requirements, the business layer is encapsulated to meet the above requirements. At the same time, other developers feel comfortable and comfortable in the call process, and the amount of code is also reduced, the upper-layer call code example is as follows:

// Sort the selected data by name
IDataResource resource = res3. GetSelectedResource ();
If (resource = null)
Return;
Resource. SortByName ();
Res3. RefreshNode (resource );

// Permission judgment
IDataResource resource = res3. GetSelectedResource ();
If (resource! = Null &&! Resource. ReadOnly)
{
Resource. Update ();
}

// Data removal
SmDatasetDirectory dir = treeRes as smDatasetDirectory;
Foreach (ListViewItem item in this. listViewUngroup. SelectedItems)
{
IDataResource res = item. Tag as IDataResource;
Dir. MoveOut (res );
}

// Delete selected data resources and their subordinates
IDataResource resource = res3. GetSelectedResource ();
Resource. Delete ();

// Add data
SmLayer layerLogic = new smLayer ("layer1 ");
MapLogic. AddResource (layerLogic );

The schematic diagram is as follows:

Main class diagram:

Design Points:

1. All business objects are data resources (even including users and roles ),UnifiedImplement top-level interfaces;

2. The top-level virtual base class implements most common functions (such as logging and sorting). Each business object only cares about its own special business;

3. Besides model data, the business object should be self-described, identify the type of its own data resources, and have permission information; 

4. The business object itself knows the objects that can be associated with, for example, whether it can be moved to a resource;

5. The business object can know which resources of its superiors are and which resources of its subordinates are;

6. When a business object is performing a database operation, it should be able to automatically record the relevant operation logs without the need for upper-layer calls to care about logs.

 

The above are some of my design practices. You are welcome to make a brick!

Download Code: BusinessLogicCommon_src.rar