One of the specific explanations in petshop4.0 (System Architecture Design)

Petshop is an example. Microsoft uses it to demonstrate. NET Enterprise system development capabilities. There are many. NET and J2EE competitions in the industry, and a lot of data comes from Microsoft's petshop and Sun's PetStore. Such a debate will inevitably have a strong commercial color. For our developers, there is no need to pay too much attention. However, with the continuous update of the petshop version, the entire design has gradually become mature and elegant, but there are many references for petshop. Petshop is a small project with simple system architecture and code, but it also highlights many valuable design and development concepts. This series tries to make a comprehensive Anatomy of petshop, according to the code is petshop4.0, able to http://msdn.microsoft.com/library/default.asp from the link? Url =/library/en-US/dnbda/html/bdasamppet4.asp.

1. System Architecture Design of petshop

In the software architecture design, hierarchical structure is the most common and important structure. The hierarchical structure recommended by Microsoft is generally divided into three layers, from the bottom to the top: The data profiling layer, the business logic layer (or the domain layer), and the presentation layer. What we can see is:

Figure 1: layer-3 hierarchical structure

Data Persistence Layer: it is also called a persistence layer. Its function is mainly responsible for database failover. Simply put, select, insert, update, and delete operations on data tables are implemented. Suppose you want to add? Orm elements include mapping between objects and data tables, and object Object persistence. In the data volume layer of petshop, the orm is not used, resulting in the addition of the amount of code ?, It can be seen as a major failure in the design implementation.

Business logic layer: it is the core of the entire system and is related to the business (domain) of the system. Taking petshop as an example, the related design of the business logic layer is related to the unique logic of pet shops on the Internet, such as querying pets, placing orders, joining? Pet to shopping cart and so on. For example, if you have questions about the database, the Data Query layer is called.

Presentation Layer: it is the UI part of the system and is responsible for user interaction with the entire system. In this layer, the ideal state should not include the business logic of the system. The logic code in the presentation layer is only related to the interface elements. In petshop, ASP. NET is used for design. Therefore, many Web controls and related logic are included.

What are the advantages of a layered structure? Martin Fowler gave the answer in patterns of enterprise application architecture:
1. developers can focus only on a layer in the entire structure;
2. It is very easy to replace the original implementation with the new implementation;
3. Reduces dependencies between layers;
4. conducive to standardization;
5. facilitate the reuse of logic at each layer.

In summary, hierarchical design can achieve the following purposes: decentralized attention, loose coupling, logic reuse, and standard definition.

A good hierarchical structure makes the division of labor of developers clearer. Once the interfaces between different layers are defined, developers responsible for different logic designs can focus on different aspects of the interface. For example, the UI personnel only need to consider the user interface experience and operations. The design personnel in the field can only focus on the design of the business logic, and the database designers do not have to worry about tedious user interaction. Every developer's task is confirmed, and the development progress can be improved quickly.

The advantage of loose coupling is obvious. Assume that a system is not layered, so their respective logics are closely intertwined and mutually dependent. No one can be replaced. Once a change occurs, the impact on the project is extremely serious. Reducing the dependence between layers can ensure the scalability of the future and obvious advantages in reusability. Once a unified interface is defined for each function module, it can be called by each module without repeated development for the same function.

The criteria for a well-designed hierarchical structure are also indispensable. This system is scalable and replaceable only on the basis of a certain degree of standardization. The communication between the layer and the layer must also ensure the standardization of the interface.

The hierarchical structure is inevitable because of the following defects:
1. reduces system performance. This is self-evident. Assuming that a layer-by-layer structure is not used, a large number of businesses can directly create a replica database to obtain the corresponding data, but now it must be completed through the middle layer.
2. Cascade changes may sometimes occur. Such changes are especially reflected in the top-down direction. Suppose you need to add? A function, in order to ensure its design conforms to the hierarchical structure, may need to be added in the corresponding business logic layer and the Data Partition layer? Corresponding code.

As mentioned above, the petshop presentation layer is designed with ASP. NET, that is, it should be a BS system. In. net, the standard BS layered structure is shown as follows:

Figure 2: Standard BS layered structure in. net

With the update of the petshop version, its layered structure is constantly intact. For example, petshop2.0 does not have a standard three-tier structure for the pipeline:

Figure 3: Architecture of petshop 2.0

We can see that there is no obvious design for the data volume layer. Although this design improves the performance of data profiling, it also leads to confusion between the business logic layer and data profiling. Once the supported databases are required to change, or the logic of Data profiling needs to be modified, there is no clear hierarchy, which will lead to major changes to the project. With the improvement of the performance of the hardware system and the full use of caching and asynchronous processing mechanisms, the performance impact of the hierarchical structure is almost negligible.

Petshop3.0 corrected the problem of unknown level and separated the data profiling logic as a separate layer:

Figure 4: Architecture of petshop 3.0

Petshop4.0 basically continued the structure of 3.0, but made some improvements in performance, introduced cache and asynchronous processing mechanisms, and made full use of ASP at the same time. NET 2.0 new features membership, so the system architecture of petshop4.0 is shown as follows:

Figure 5: Architecture of petshop 4.0

The core content of the system architecture diagram is not changed. In the data volume query layer (DAL), the volume still abstracts the data volume query logic using the Dal interface, and uses the Dal factory as the factory module of the data volume query layer object. For the Dal interface, the SQL Server Dal that supports the MS-SQL and the Oracle Dal that supports the Oracle are specific implementations, respectively. The model module includes data entity objects. The specific module structure is shown below:

Figure 6: module structure of the data challenge Layer

We can see that in the Data profiling layer, the idea of "interface-oriented programming" is fully applied. The abstracted idal module is independent from the detailed database, so that the entire data failover layer facilitates database migration. The dalfactory module is dedicated to managing creation of Dal objects, which is convenient for the business logic layer. The sqlserverdal and oracledal modules both implement the idal module interface, which includes the select, insert, update, and delete operations on the database. Because of the different database types, database operations are also different, and the code is also different.

In addition to removing the downward dependency, the abstracted idal module only has weak dependencies for the business logic layer on it. For example, see:

Figure 7: module structure of the business logic layer

In Figure 7, BLL is the core module of the business logic layer, which includes the core business of the entire system. In the business logic layer, databases cannot be directly asked, but must be accessed through the data pipeline layer. Note that in the figure, the call to the data producer service is completed through the interface module idal. Since it has nothing to do with the detailed data query logic, the relationship between the layer and the layer is loosely coupled. If you need to modify the detailed implementation of the Data Transport question layer at this time, and do not involve the idal interface definition, the business logic layer will not be affected at any time. After all, the detailed implementation of sqlserverdal and oracaldal have no relationship with the business logic layer.

The asynchronous processing mechanism is introduced in petshop 4.0. The insert order policies can be divided into synchronous and asynchronous policies. The insert policies of the two are obviously different, but for callers, the interface for inserting orders is the same, so the ibllstrategy module is designed in petshop 4.0. Although in the ibllstrategy module, the simple iorderstategy provides an example and information at the same time, that is, in the processing of business logic, assuming that there are diversified business operations, or possible future changes should use abstract principles. You can also use interfaces or abstract classes to remove the dependency on detailed services. However, in petshop, because the business logic is relatively simple, this idea is not obvious enough. Because of this, petshop puts the core business logic in a module Bll, and does not strictly separate the detailed implementation from the abstraction according to the module. Therefore, the call relationship between the presentation layer and the business logic layer is highly coupled:

Figure 8: module structure of the Presentation Layer

In Figure 5, auxiliary modules are also introduced in each layer, such as the messaging module of the Data consumer question layer, which provides the function of Asynchronously inserting orders, the producer uses the MSMQ (Microsoft messaging Queue) technology. The cachedependency of the presentation layer provides the cache function. I will introduce these special modules in the subsequent articles.