"Anatomy PetShop" one of: PetShop system Architecture Design _ self-study Process

Source: Internet
Author: User
Tags abstract

Foreword: PetShop is an example, Microsoft uses it to show. NET Enterprise system development ability. There are many in the industry. NET and the Java EE dispute, many data is from Microsoft's PetShop and Sun's petstore. This argument inevitably has a strong commercial color, for our developers, there is no need to pay too much attention. However, PetShop with the release of the continuous update, to now based on the PetShop4.0 of. Net 2.0, the whole design gradually matured and elegant, but there are many lessons to learn from. PetShop is a small project, system architecture and code are relatively simple, but also highlights a lot of valuable design and development concepts. This series attempts to make a full anatomy of the PetShop, based on the code PetShop4.0, which can be http://msdn.microsoft.com/library/default.asp?url=/library/en-us/from the link Dnbda/html/bdasamppet4.asp.

System Architecture Design of PetShop

In software architecture design, layered structure is the most common and most important structure. Microsoft's recommended layered structure is generally divided into three layers, from the bottom to the following: Data access layer, business logic layer (or to become a domain layer), the presentation layer, as shown in the figure:


Fig. 1:3 Layered Structure

Data access layer: sometimes called the persistence layer, its function is mainly responsible for database access. The simple argument is to implement the select,insert,update,delete of the datasheet. If you want to add an ORM element, you will include the mapping between the object and the datasheet, and the persistence of the object entity. In the PetShop data Access layer, ORM is not used, resulting in an increase in code volume that can be seen as a major failure in the overall design implementation.

Business Logic Layer: The core of the entire system, it is related to the business (domain) of the system. In the case of PetShop, the relevant design of the business logic layer is related to the logic of the online pet shop, such as searching for pets, placing orders, adding pets to shopping carts and so on. If access to the database is involved, call the data access layer.

Presentation layer: The UI part of the system that is responsible for the interaction of the user with the entire system. In this layer, the ideal state is not to include the system's business logic. The logical code in the presentation layer, only related to the interface element. In PetShop, it is designed using asp.net, so it contains a number of Web controls and related logic.

What is the advantage of layered structure? Martin Fowler the answer in the book Patterns of Enterprise Application Architecture:

1, developers can only focus on the entire structure of one of the layers;
2, can be easily replaced by the new implementation of the original level of implementation;
3, can reduce the layer and the dependence between layers;
4, conducive to standardization;
5, conducive to the reuse of the logic of each layer.

Broadly speaking, layered design can achieve the following objectives: distraction, loose coupling, logical reuse, standard definition.

A good layered structure can make the division of the developer more clear. Once the interfaces between the layers are defined, developers who are responsible for different logical designs can be distracted and go hand in hand. For example, the UI staff only need to consider the user interface experience and operations, the domain designers can focus on the design of the business logic, and database designers do not have to worry about cumbersome user interaction. Each developer's task is validated and development progress can be rapidly improved.

The benefits of loose coupling are obvious. If a system is not layered, then the logic of each is tightly intertwined and interdependent, and no one can be replaced. Once the change is far-reaching, the impact on the project is extremely serious. Reducing the dependence between layer and layer can not only guarantee the future scalability, but also have obvious advantages in reusability. Once each functional module is defined as a unified interface, it can be invoked by each module instead of repeated development for the same function.

The standard is also essential for good layered structural design. This system is extensible and replaceable only on a certain level of standardization. And the communication between layer and layer is bound to ensure the standardization of interface.

"Gold without pure, no perfect", layered structure also inevitably has some defects:

1, reduce the performance of the system. This is self-evident. If you do not use a layered structure, many businesses can visit the database directly to obtain the appropriate data, but now must be done through the middle tier.
2, sometimes lead to cascading changes. This change is especially true in the top-down direction. If you need to add a feature to the presentation layer, to ensure that its design conforms to a layered structure, you may need to add code to the appropriate business logic layer and data access layer.

As mentioned earlier, the presentation layer of the petshop is designed using asp.net, i.e., it should be a BS system. In. NET, the standard BS layered structure is shown in the following illustration:


figure II:. Standard BS layered structure in net

With the PetShop version of the update, its layered structure is also constantly improved, such as PetShop2.0, there is no standard three-layer structure, as shown in Figure three:


Figure Three: Architecture of PetShop 2.0

We can see from the diagram that there is no obvious data access layer design. While this design improves the performance of data access, it also leads to confusion in the responsibilities of the business logic layer and data access. Once the requested database changes, or the logic of data access needs to be modified, there is no clear layering that can cause the project to make major changes. With the improvement of the performance of the hardware system and the full use of caching and asynchronous processing mechanisms, the performance impact of layered structure can be negligible.

PETSHOP3.0 corrects previously unknown levels of data access logic as separate layers:


Figure IV: The architecture of PetShop 3.0

PetShop4.0 basically continued the structure of 3.0, but the performance of a certain improvement, the introduction of caching and asynchronous processing mechanism, while taking full advantage of the ASP.net 2.0 new features membership, so the PetShop4.0 system architecture diagram is as follows:


Figure Five: Architecture for PetShop 4.0

Compared to the 3.0 and 4.0 system architecture diagrams, the core content has not changed. In the data Access Layer (DAL), the data access logic is still abstracted from the Dal interface, and the Dal factory is used as the factory module of the data Access Layer object. For DAL interface, there are ms-sql SQL Server dal and Oracle DAL implementations that support Oracle respectively. The model module contains the data entity objects. Its detailed module structure diagram looks like this:


Figure VI: module structure diagram of the data access layer

As you can see, in the data access layer, the idea of "interface-oriented programming" is fully adopted. The abstracted Idal module, which is separated from the concrete database, makes the whole data access layer facilitate the database migration. The Dalfactory module manages the creation of Dal objects to facilitate business logic layer access. Both the Sqlserverdal and Oracledal modules implement the interface of the Idal module, which contains the logic of select,insert,update and delete operations on the database. Because of the different types of databases, the operation of the database differs, and so does the code.

In addition, the abstraction of the Idal module, in addition to lifting down the dependency, for the business logic layer, the same only weak dependencies, as shown in the following figure:


Figure VII: module structure diagram for the business logic layer

In Figure VII, BLL is the core module of the business Logic layer, which contains the core business of the whole system. In the business logic layer, the database cannot be accessed directly, but must pass through the data access layer. Note that the call to the data access business in the graph is accomplished 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 implementation of the data access layer at this point, the business logic layer will not be affected as long as the Idal interface definition is not involved. After all, the implementation of Sqlserverdal and oracaldal at all has nothing to do with the business logic layer.

Because the asynchronous processing mechanism was introduced in PetShop 4.0. The strategy for inserting an order can be divided into synchronous and asynchronous, with a significantly different insertion strategy, but for the caller, the interface for inserting the order is exactly the same, so the Ibllstrategy module is designed in PetShop 4.0. Although the Ibllstrategy module is simply a iorderstategy, it also gives an example and information that, in the process of business logic, if there is a diversification of business operations, or possible future changes, should use the abstract principle. Or use an interface, or use an abstract class to disengage from reliance on specific business. But in PetShop, the idea is not obvious because the business logic is relatively simple. Also because of this, petshop the core business logic into a module BLL, and does not have the specific implementation and abstract strictly according to the module separate. Therefore, the invocation relationship between the presentation layer and the business logic layer is relatively high in coupling degree:


Figure Eight: The module structure diagram of the presentation layer

In Figure V, auxiliary modules, such as the messaging module of the data Access layer, are introduced at various levels to provide an asynchronous insertion order feature, using MSMQ (Microsoft messaging Queue) technology. The cachedependency of the presentation layer provides caching functionality. These special modules, which I will explain in detail in the following articles.

The above is PetShop system architecture of the whole content, hope to give you a reference, but also hope that we support the cloud habitat community.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.