Learning notes for enterprise solutions using Microsoft. NET (4) Business Layer

 

Business Layer

 

 

Introduction

Martin Fowler said: "Anyone can write code that computers can understand. Only programmers who write code that people can understand are good programmers ."

Every complex software should be organized by layer. Each layer represents a logical part of the system. In particular, the business layer module includes all functional algorithms and computing required for interaction with other layers during system operation. The other layers include the data access layer dal and presentation layer.

The business layer is the neural center of any layered system and contains most of the core logic. For this reason, it is also often called the business logic layer BLL.

Body

1. What is the business logic layer?

Abstract: The business logic layer is a part of the system used to process business-related tasks. Essentially, the business logic layer includes a series of operations to execute data. Data is modeled as the entity of the problem domain, such as invoice, user, order, and list. On the other hand, it includes some operations, such as creating an invoice, adding a user, and processing an order.

2. Analyze the Business Layer

If you look at the business logic layer from the vertical perspective, you will find some business model entities, express the business rules of user policies and requirements, and implement automated services, define a workflow for transferring documents and data from one layer to another.

Security is a serious problem that needs to be considered at all layers, but at the business logic layer, the Code acts as a hacker at the user interface layer. The security at the business logic layer is role-based, or restrict access to business objects, which is only open to authorized users.

2.1 domain object model

The domain object model is more inclined to provide a structured view of the entire system, including the functional description of the entity, the relationship between entities, and the responsibility of the entity. The model is generated from user requirements and documented using the UML use case diagram and class diagram. In the model, you represent the real-world elements used to store data and expose operations. Each entity represents a role in the model and provides some actions. Each entity has its own responsibilities and interacts with each other based on the relationship between fields.

Many applications are marked with complex tags. In fact, if you see the final technical implementation, you will find it relatively simple. However, as a whole, this application is complicated because of the inherent complexity of the domain. Generally, the difficulty lies in building an appropriate software model, rather than the final implementation. A well-designed model can solve any complexity wherever you run it.

　　

Object Model and Domain Model

For clarity, let's determine the words "Object Model" and "domain model. Although we often use them in turn, they represent different things. Even if they represent the same thing, their abstraction levels are different. The so-called "Object Model" is a simple object graph. There are no restrictions on how to design and implement models. If you have some correlated classes, you have an object model. As you can see, the description is quite generic and applicable to most solutions.

Our so-called "domain model" is another thing. The domain model is an object model that meets a series of requirements. Typically, a class in a domain model does not have a persistent layer. It is an ideal state that is irrelevant to classes in other help class libraries. In addition, domain models are designed to solve specific domain problems, and try to abstract business processes and data streams from the relationship between entities and them.

Remember that domain models are also a special design model, which will be discussed later.

2.2 domain entity

From the external perspective, the business logic layer is a series of operations on business objects. In most cases, a business object is the implementation of a domain entity, that is, a class that encapsulates data and behavior. It may also be some auxiliary classes that implement special computing. The business logic layer determines how Business Objects interact. It also imposes rules and processes on the modules and business objects involved in interaction.

The business logic layer is in the middle of a hierarchical system, and exchanges information with the presentation layer and data access layer. The input and output of the business logic layer are not mandatory for business objects. In most cases, architects prefer to use DTO (data transfer objects) for data transmission across layers.

What are the differences between business objects and data transmission objects?

Business Objects include data and behaviors. In business logic, they can be seen as congested activity objects. A Data Transmission object is only a value object and contains no additional data. For the purpose of serialization, the data stored in the business object needs to be serialized into the data transmission object. Data transmission objects have no logical behavior except setter and getter. In the model, each domain entity class may correspond to multiple data transmission objects. Why are multiple data transmission objects?

A Data Transmission object is not a simple copy of a non-behavior domain object. On the contrary, a data transmission object represents a subset of domain objects used in a specific context. For example, in a method, you need a customerdto with only name and ID. In other places, you may need a customerdto with name, ID, country, and contract. Generally, a domain object is a graph containing many objects, for example, a customer contains orders, orderdetails, and so on.

 

Key Points

The collaborative use of DTO and ob can lead to a series of meaningless arguments. Theoretically, we recommend that you use DTO to reduce the coupling between layers in any case. In practice, we often remind us that it is complicated enough to avoid unnecessary additional things. As a practice principle, we recommend that you do not need to do this when dealing with models of less than 100 business objects. In these cases, DTO and ob may be very similar.

2.3 Business Rules

Organizations in the real world are made up of a series of business rules. You can argue about the level of these rules, but you cannot deny the existence of these rules. Every organization has a strategy to pursue. Rules are the main criterion for achieving the strategy. The strategy specifies the height to be reached, and the rules specify how to reach this height.

There are various ways to standardize business rules. If you live and work in a perfect world, every organization maintains its own rule database, so that these rules can be easily shared among various teams in a project. This is not the case in most cases. The process of collecting business specifications begins with the development project. The result is that the business rules are sorted out at the end of the project and shared among architects.

Depending on the context of the operation, the business rules are not fixed and changed. This means that in the business logic layer, rules should be implemented in a flexible way, preferably through the rule engine. In the highest level abstraction, the rule engine is a part of the software. It introduces rules with certain specifications and applies them to business objects.

In reality, business rules are usually a series of if... Else... The operation mapped to the business object, that is, the business logic.

In the actual system, a business object may map thousands of rules. Your rule engine should be flexible enough to adapt to possible changes and fix some misunderstandings.

2.4 Verification

The attributes of a business object come from the attributes of an object. The methods of business objects come from a series of responsibilities.

 

Source: http://www.cnblogs.com/virusswb/archive/2010/08/20/architecture-microsoft-net-solution-4.html