Bruce Zhang, one of the anatomy petshop Series)

Anatomy petshop Series

Preface: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 many data comes from Microsoft's petshop and Sun's PetStore. This debate inevitably has a strong commercial color, and we do not need to pay too much attention to it for our developers. However, with the continuous update of petshop versions, the entire design has gradually become mature and elegant, but there are a lot to learn from. NET 2.0-based petshop4.0. 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, based on the Code is petshop4.0, can be from the linkHttp://msdn.microsoft.com/library/default.asp? 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: data access layer, business logic layer (or domain layer), and presentation layer ,:

Figure 1: layer-3 hierarchical structure

Data access layer: it is also known as the persistent layer. Its function is mainly to access the database. Simply put, select, insert, update, and delete operations on data tables are implemented. If you want to add an ORM element, it will include mapping between the object and the data table, and object Object persistence. In the data access layer of petshop, Orm is not used, which leads to an increase in the amount of code. It can be seen as a major failure in the entire 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, adding pets to the shopping cart, and so on. If database access is involved, the data access 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, it contains many Web controls and related logic.

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

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

A good hierarchical structure can make the Division of Labor clearer for developers. Once the interfaces between different layers are defined, developers responsible for different logic designs can focus on them separately and go hand in hand. For example, the UI staff only need to consider the user interface experience and operations. The design staff 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. Each developer's task is confirmed, and the development progress can be improved quickly.

The benefits of loose coupling are obvious. If a system is not layered, the logic of each system is 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.

A good hierarchical structure design is also essential. This system is scalable and replaceable only on the basis of a certain degree of standardization. The communication between layers also ensures the standardization of interfaces.

The hierarchical structure is inevitable because of the following defects:
1. Reduced system performance. This is self-evident. If the hierarchical structure is not used, many businesses can directly access the database to obtain the corresponding data, but now it must be done through the middle layer.
2. Cascade modifications may sometimes occur. This kind of modification is especially reflected in the top-down direction. If you need to add a function in the presentation layer, to ensure its design conforms to the hierarchical structure, you may need to add the corresponding code in the corresponding business logic layer and data access layer.

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 in:

Figure 2: Standard BS layered structure in. net

As the petshop version is updated, its layered structure is constantly improved. For example, petshop2.0 does not adopt a standard three-tier structure:

Figure 3: Architecture of petshop 2.0

We can see that there is no obvious data access layer design. Although this design improves the performance of data access, it also leads to confusion in the business logic layer and data access responsibilities. Once the supported databases are required to change or the data access logic needs to be modified, the project may be greatly modified because there is no clear hierarchy. 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 access 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. the new membership of NET 2.0, so the system architecture of petshop4.0 is as follows:

Figure 5: Architecture of petshop 4.0

Compared with the system architecture diagram of 3.0 and 4.0, its core content has not changed. In the data access layer (DAL), the Dal interface is used to abstract the data access logic and the Dal factory is used as the factory module of the data access 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 contains data entity objects. The detailed module structure is as follows:

Figure 6: module structure of the data access layer

We can see that the "interface-oriented programming" concept is fully adopted in the data access layer. The abstracted idal module is independent from the specific database, so that the entire data access layer facilitates database migration. The dalfactory module manages creation of Dal objects to facilitate access to the business logic layer. Both the sqlserverdal and oracledal modules implement the idal Module Interface, which contains 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 on the business logic layer, as shown in:

Figure 7: module structure of the business logic layer

In Figure 7, BLL is the core module of the business logic layer. It contains the core business of the entire system. In the business logic layer, the database cannot be accessed directly, but must be accessed through the data access layer. Note that the data access service is called through the interface module idal. Since it has nothing to do with the specific data access logic, the relationship between the layer and the layer is loosely coupled. If you need to modify the specific implementation of the data access layer, as long as the idal interface definition is not involved, the business logic layer will not be affected. After all, the specific implementation of sqlserverdal and oracaldal have no relationship with the business logic layer.

This is because 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 for 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 the ibllstrategy module only provides a simple iorderstategy, it also provides an example and information, that is, in the processing of business logic, if 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 specific services. However, in petshop, because the business logic is relatively simple, this idea is not obvious enough. Because of this, petshop puts all the core business logic in a module Bll, and does not strictly separate the specific implementation and abstraction by 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 at various layers, such as the messaging module at the data access layer, which provides the asynchronous order insertion function and uses MSMQ (Microsoft messaging Queue) technology. The cachedependency of the presentation layer provides the cache function. I will introduce these special modules in detail in subsequent articles.

From: http://www.cnblogs.com/wayfarer/archive/2006/04/14/375382.aspx