Step by step. NET three-layer architecture Analysis VI. BLL Design

The BLL layer is also called the business logic layer. As the name suggests, it is the place where the business logic is placed.

The business logic layer is critical to the architecture. It is in the middle of the data access layer and the presentation layer, and plays a role in data exchange. Because the layer is a weak coupling structure, the dependency between the layer is downward, and the underlying layer is "ignorant" for the upper layer, changing the design of the upper layer has no impact on the underlying layer of its calls. If the hierarchical design follows the interface-oriented design idea, this downward dependency should also be a weak dependency. Therefore, without changing the interface definition, the ideal layered architecture should be a "drawer" architecture that supports extraction and replacement. Because of this, the design of the business logic layer is critical to an architecture that supports scalability, because it plays two different roles. For the data access layer, it is the caller; for the presentation layer, it is the caller. Dependencies and dependencies are all entangled in the business logic layer. How to decouple dependencies is a task left to designers apart from implementing business logic.

Let's talk about some other things here for everybody to entertain.

In his book "enterprise application architecture model", Martin Fowler summarized the architecture model of the domain layer (namely the business logic layer). He divided the business logic design into three main models: transaction Script, Domain Model, and Table Module.

The Transaction Script Mode regards the business logic as a process, and is a typical process-oriented development mode. You can use the Transaction Script Mode to directly access the database without the data access layer. To effectively manage SQL statements, you can place database access-related behaviors in a dedicated Gateway class. The application of the Transaction Script Mode does not require much object-oriented knowledge. The simple and direct feature is the full value of this mode. Therefore, many projects with relatively simple business logic apply the Transaction Script Mode.

The Domain Model mode is a typical embodiment of object-oriented design ideas. It fully considers the complexity and variety of business logic, introduces design patterns such as the Strategy model, and implements scalability of the model by establishing domain objects and abstract interfaces, it also utilizes the inherent characteristics of Object-oriented Thinking, such as inheritance, encapsulation, and polymorphism, to process complex and variable business logic. The only application that restricts this mode is the ing between objects and relational databases. We can introduce the ORM tool or use the Data Mapper mode to map the relationship to the object.

Similar to the Domain Model pattern, the Table Module pattern also has the idea of object-oriented design. The only difference is that the object it obtains is not a pure Domain object, but a DataSet object. If you create a simple ing relationship between a relational data table and an object, the Domain Model mode creates a Domain object for each record in the data table, the Table Module mode regards the entire data Table as a complete object. Although the use of the DataSet object will lose the basic features of object-oriented, it has a unique advantage in providing data source support for the presentation layer. Especially on the. Net platform, ADO. NET and Web controls provide a fertile ground for the growth of the Table Module model.

Now, let's design customSystem. cs:

View sourceprint? Public class customSystem

{

Public ICustom CustomSQL = new customSQL ();

/// <Summary>

/// Add a data entry

/// </Summary>

/// <Param name = "Custom"> </param>

/// <Returns> </returns>

Public int customADD (custom Custom)

{

If (Custom = null)

{

Return 0;

}

Return CustomSQL. Addcustom (Custom );

}

/// <Summary>

/// Obtain user information based on the account name

/// </Summary>

/// <Param name = "nename"> </param>

/// <Returns> </returns>

Public custom GetSinglename (string nename)

{

If (string. IsNullOrEmpty (nename ))

Return null;

Return CustomSQL. Getsinglecname (nename );

}

/// <Summary>

/// Update user information (mainly used to change the password)

/// </Summary>

/// <Param name = "Custom"> </param>

Public void Updatepassword (custom Custom)

{

If (Custom = null)

Return;

CustomSQL. Updatepassword (Custom );

}

/// <Summary>

/// Obtain the user list

/// </Summary>

/// <Returns> </returns>

Public List <custom> GetCustom ()

{

Return CustomSQL. Getcustom ();

}

/// <Summary>

/// Delete user information by ID

/// </Summary>

/// <Param name = "nid"> </param>

Public void Deletecustom (int nid)

{

If (nid <= 0)

Return;

CustomSQL. Deletecustom (nid );

}

/// <Summary>

/// Obtain user information by ID

/// </Summary>

/// <Param name = "nid"> </param>

/// <Returns> </returns>

Public custom GetCutomer (int nid)

{

If (nid <= 0)

Return null;

Return CustomSQL. Getcustomer (nid );

}

/// <Summary>

/// Update user information

/// </Sum