. NET Enterprise Application Architecture Design-Business Layer Design

Business Layer Analysis

Any complicated software can be organized through layers. Each layer represents a logical part of the system. Generally, the module in the business logic layer includes algorithms and computing processes for all functions required by the system, and interacts with the data layer and the presentation layer. Abstract: The business logic layer is a part of the software's ability to handle business-related task performance.

The business logic layer indicates the system logic. The code here will make necessary decisions and perform operations. As mentioned above, security at the business logic layer means that role-based security principles are used to only allow authenticated users to access specific business objects. From the outside, the business logic layer can be seen as a mechanism for operating business objects. Generally, business objects are only the implementation of a certain domain entity or a certain type of auxiliary type for executing some calculations. The business logic layer is in the middle of a layered system. The input and output of the business logic layer are not necessarily Business Objects. In many cases, architects prefer to use data migration objects to exchange data between layers.

The trade-off between data migration objects and Business Objects has always been a topic of controversy in the team. It is recommended to use the theory of data migration objects that data migration objects can reduce coupling between layers and make the system more clean and tidy. However, in reality, people will say that the complexity is already high, so we should avoid adding unnecessary objects. One practical principle is that when there are already hundreds of business objects, it may not be necessary to simply double the number to make the design clean. In this case, data Migration objects are usually business objects. The business object contains both data and behavior, and is a complete object that can participate in the domain logic. The data migration object is more like a value, that is, a series of data containers without relevant behavior. For serialization, data in the business object is copied to the data migration object. Except the get/set accessors, data migration objects do not have logical behavior. The data migration object does not only remove the behavior of the domain object. It represents a subset of the objects in a specific domain and is used in a special context. Generally, a domain object is an object graph, and a data migration object is only a projection of some required data.

Every real world organization runs based on a series of business rules. Many people may not recognize these rules in the Organization, but cannot deny them. Each organization has its own strategy, and business rules are the main means to ensure the implementation of these strategies. The Strategy determines the development direction of the organization, and the business provides specific practices for implementing the strategy.

The attributes of a business object come from the attributes of the ing object. The Business Object method comes from its own responsibilities and some business rules applied to the object. In many ways, Business Rules validate data. In other words, many business rules verify the current content of a business object. According to this understanding, this design will be very good if there is a dedicated verification layer and the support available for business objects.

The business logic layer should not be regarded as a whole component or a combination of unrelated modules. Years of practical experience tell us that appropriate repetition of the business logic layer in other layers (Classic Layer 3) is acceptable and is also the practice of many programs. However, this practice has limits and should not be encouraged.

Business Layer and other Layer

Suppose we have a classic hierarchical system that includes the presentation layer, business layer, and data access layer. What is the percentage of business logic distributed in each layer? The most authoritative answer is 0-100-0. This number is obviously unrealistic. Generally, you should try to put everything on the business logic layer, except for crdu operations and user interface adjustments. The logic dispersed in the presentation layer and data access layer may be repeated only in terms of performance. These repetitions are caused by the gray areas of the overall functions of some systems. Sometimes we don't know where to place them. Below we will introduce several common gray areas.

1. data formatting. For Visualization on the client, the presentation layer must understand a lot of context and system logic. If formatting is placed on the business logic layer, the business logic layer must provide appropriate methods for the client to call and obtain strings that can be directly displayed. We have several options. The first is to store the original data and formatted data. The second is to store raw data and format it as needed. The third is to store the data in the input format. Of course we will choose the second type.

2. CRUD operation. The data access layer should only be used to process database-related operations, and business logic judgment must call data.

3. stored procedures. The reason is similar to crud access. When it comes to database traffic, you can add hardware or replace better hardware. In addition, you can cache the data in the business logic layer.

Business layer mode Differentiation

There are several options for the business layer mode. The first is the procedural mode. Before the rise of object-oriented development, business logic is just a collection of processes, each of which is used to process a request from the presentation layer. Therefore, a good design is to better organize these processes and reduce code and process redundancy. The higher the degree of abstraction of Object-based models, the larger the gap with the data model. Therefore, to create a domain-driven object model, we should generally focus on the domain rather than the database structure. Domain-driven design will certainly make the database model and domain model quite different. This mode is usually called a domain model.

The object-based model has a high price in the beginning, but with the increase of complexity, the cost also increases linearly. In other words, once you have a good understanding of the domain model, you can use the domain model regardless of the complexity of the system. In terms of complexity measurement, complexity is divided into two aspects. The first is inherent, inevitable, and unable to coordinate the demand itself. Such complexity can be reduced by some methods, but it cannot be completely erased, must be directly faced. The second is the complexity of the Introduction. This is due to the inconsistency of the opinions of stakeholders of different projects. The negative effect is to direct the team to the wrong direction, the wrong direction will allow the abstract design to include unnecessary or non-functional functions, forcing the software to break down.

The number of requirements can be used to roughly determine the complexity of the system, recognizing the complexity is easier than explaining how to find the complexity.

Transaction Script Mode

The transaction script mode may be the simplest mode in the business logic layer. It is a pure procedural mode. The transaction Script Mode encourages you to discard all the object-oriented designs and map the business directly to the user operations you need. This mode focuses on the operations that you can perform through the presentation layer, write a special method for each operation. The transaction Script Mode is easy to understand and interpret, and each required user operation starts in a physical transaction. However, data access is typically encapsulated in other components and does not belong to scripts. Transaction scripts are suitable for simple scenarios where the business logic is very simple and is unlikely to change. It is very difficult to weigh the concept of simplicity and complexity. More importantly, the perception of simplicity and complexity also depends on the attitude and ability of a person. You know!

Simplicity is the most notable advantage of the transaction script mode, but the transaction script has the potential to cause code duplication. All types that implement transaction scripts can be seen as business components. Each business component can have one or more transactions. A popular design method is to group each transaction script and then make each transaction component A business component, so that the transaction scripts in each group are logically related. Another approach is to encapsulate each transaction script with a separate class so that each business component contains only one method. In other words, the business component becomes a bunch of command objects. If you want to design the business component of the transaction script as a command object, you can release an interface and expose all required parameters in the form of public properties.

Table module Mode

Compared with the transaction script, the table module is more structured. The table module acts as a container to combine data and behavior. The business logic is split into coarse-grained components that represent the entire data table. The granularity of the table module does not decrease to the level of data rows, that is, the table module class cannot distinguish each row of data. In table module mode applications, using a record set-based data structure is the most common method. Such as dataset and able.

For scenarios that do not require too much abstraction and there is no big difference between the data model and the object model, the table module is a very good compromise. Compared with the transaction script, the table module is based on a conceptual model. Instead of a loose set of a large number of methods. If both the presentation layer and the data access layer are based on the table-like data structure, the table module is a good choice. In this case, the business layer can provide directly available data for the presentation layer, sometimes it can even be implemented directly through data binding.

The table module is not much more complex than the transaction script. However, IF Manual construction is required, it may take much more time than the simple transaction script. While providing more guidance, the pattern also means that we need to consider more rules, that is, writing more code.

The embedded Dataset Designer provides the fill and getdata methods to query the entire data table. From a conceptual perspective, another advantage of the table module is that no matter what the underlying data source is, the same table module class will be available for the same functions. The table module is based on objects, but is fully database-driven. The table module is not suitable for describing complex entities. Especially when there is a significant gap between the object model and the data model. The advantage of the table module is that vs provides powerful support and is easy to implement. However, considering that the generated code is similar to a black box, the advantage has become a disadvantage. Of course, the structure model of the table module does not need to be closely coupled with.

Activity record mode

Both the transaction script and the table module are in the procedural mode. However, the table module is based on objects rather than an object-based business logic modeling model. The key step toward object-oriented design is to recognize the target object in the system. The business logic and domain logic are the core of the system. They are composed of the necessary interactions between entities.

Activity logging is a relatively simple domain model, but it is still based on the object mode. An easier way to understand is that activity records are based on rows in a data table, rather than data tables in a table module. That is to say, activity records have row-level granularity for data, while the table module focuses on the entire table. The activity record mode is classified as the data source design mode, rather than the business logic mode. The activity record mode is an object that encapsulates a row of a data table or view. An object can contain both data and behavior, the structure of the activity record object should be as close as possible to the associated data table structure.

In applications without a service layer, the activity record mode can be used in combination with the transaction script.

The success of the activity recording mode depends on two factors: simplicity and framework. These two factors are closely related. What we are most familiar with most is LINQ-to-SQL. Compared with simple logic, activity records are very suitable. Another issue with activity records is the binding between objects and database table designs. If you have to modify the database, you also need to modify the activity record object model and all relevant code. From this perspective, the activity record is on the opposite side of the domain-driven architecture.

Domain-driven model

When designing domain logic, if a procedural method or activity recording mode is selected, the data-centric approach is actually adopted. The business model is designed not for the business itself, but for the data used in the business.

In the long run, the data-centric approach does not well adapt to the increase in scale. Because when the complexity of the system reaches a certain limit, even new requirements are added, it will become difficult to solve. Domain Models focus on the expected behaviors of the system and the data required for normal system operations. Domain-driven design strives to keep its complexity within a controllable (although still very high) range. The domain-driven design does not necessarily need to use the domain model, but the domain model is the most natural choice.

The domain model describes the entities involved in the system, captures the relationships between entities, and the process of data exchange in the system. Domain models are not software at the moment, nor do they involve any software or implementation concepts or principles. The domain model is just a formal model that enables technical teams and business teams to understand each other and communicate well. The domain model can be viewed as the "Big Brother" of activity records. The domain model is completely independent from the database and is a model that is as close as possible to the real process. The domain model mode makes System Modeling very flexible and free, without the need to consider platform and database constraints. In addition, domain-driven design is a way to look at design, so skills and attitudes play an important role.

In a domain model, the concept is used for modeling. This method makes full use of the advantages of object-oriented design. You can use all the features of object-oriented, including encapsulation and inheritance, at the same time, there is no need to be limited by the database structure, which means that the entity will not notice any persistence mechanism related to the underlying use. The domain model is demand-driven. You only need to understand the problem domain and use the class to model the logic. The main obstacle to implementing domain models is the mismatch between objects and relational databases. Domain Models are an object-oriented design that is completely independent of the constraints of databases or other applications, limited by the business processes it models, this means that the same domain model can be reused in any scenario that requires the same logic. The model is business-related and only business-related.

Without any o/R ing tool, such as nhib.pdf, it is difficult to implement the domain model mode.

Summary

Business Logic is the core of the system, but it is not the whole system. The Business Logic Design Option will affect other layers, especially the persistence and data access layers. The two layers add up, which will affect the project's success or failure.

Related blogs:

• . Net enterprise-level application architecture design: Contemporary architects and Architectures
• . NET Enterprise Application Architecture Design-UML
  
• Design principles and models for. net enterprise-level application architecture design
• . NET Enterprise Application Architecture Design-Business Layer Design
• . Net enterprise-level application architecture design-service layer design
• . Net enterprise-level application architecture design-data access layer
  
• . Net enterprise-level application architecture design-Presentation Layer Design