Architecture Summary of Software

Excerpt from the original link: Yesky

Common Software Architecture

L Three-tier architecture

In the design of software architecture, layered structure is the most common and most important structure. The layered structure is generally divided into three layers, from bottom to top: The data access layer, the business logic layer (or become the domain layer), the presentation layer:

　　

Figure 23 Layer Architecture

Data Access layer: sometimes also known as the persistence layer, its function is mainly responsible for database access. The simple argument is to implement the select,insert,update,delete of the data table. If you want to add an ORM element, it will include the mapping between the object and the data table, and the persistence of the object entity.

Business Logic Layer (BusinessRules): is the core of the entire system, which is related to the business (domain) of this system. In the case of STS system, the related design of business logic layer is related to the logic of sales tracking. Structurally, it encapsulates the related operations of the data access layer. This layer consists primarily of classes that implement specific business logic.

Presentation Layer (WebUI): Is the UI part of the system that is responsible for user interaction with the entire system. In this layer, the ideal state is that the business logic of the system should not be included. Represents the logical code in a layer, which is related only to interface elements. In the current project, it is designed with ASP., so it contains many Web controls and related logic.

L Five-tier architecture

SaaS software architecture can also be divided into five tiers, from top to bottom: User interface layer (presentation layer), Business logic layer, universal layer, Application framework layer, remote access (WebService) layer, data access layer:

　　

Figure 3 is based on Microsoft. NET Architecture Design

User interface Layer (UI)

The user interface layer is the user interface that is directly manipulated. This layer is composed of the interface appearance, form controls, frames, and other parts. The user interface layer is responsible for the interaction of the consumer with the entire system. In this layer, the ideal state is that the business logic of the system should not be included. Represents the logical code in a layer, which is related only to interface elements. In the current project, it is designed with ASP., so it contains many Web controls and related logic.

² interface appearance including Skip (skin), Images (picture), CSS (style sheet)

² form controls mainly include common forms, user-defined controls.

² The framework mainly includes the master page, frame page.

² Other main include JavaScript files, DLL files, report reports, schema database, model development template.

Business Logic Layer (BusinessRules)

Is the core of the entire system, and it is related to the business (domain) of the system. In the case of STS system, the related design of business logic layer is related to the logic of sales tracking. Structurally, it encapsulates the related operations of the data access layer. This layer consists primarily of classes that implement specific business logic.

²blfactory Business Logic Factory

²IBL Business Logic Interface

²businessrules Business Logic Implementation

Universal Layer

The general-purpose layer runs through the presentation and business logic layers of the entire project. The main storage of the project is the more general definition of constants and common services (service), here refers to the service is the current project business logic common method, we write them in the corresponding static class. Provided in the form of a service.

Commonlayer: Storage of common constants and methods.

Data Access Layer

The layer structure is the most complex, consisting mainly of the following layers: The data Access Factory layer (dalfactory), the Data Access Interface layer (Idal), the custom query layer (PERSISTENCEFACADE), the staging layer (Dataaccesslayer), the Data Persistence layer ( Persistencelayer).

The following is introduced from the bottom up:

²persistencelayer layer, which is the lowest level of the frame design (except the application framework layer). It is primarily responsible for using ORM ideas to target physical databases. The simple thing is to map the database table to an entity class and map the corresponding fields to the properties of the class. In this way the physical database is completely transparent to the developer, and the idea of applying ORM is completely free of the physical database. and is independent of the database specific implementation.

² specifically implement our lightweight data access component Activerecorder implemented under the well-known open source project Castle.

²persistencefacade layers and Idal, which define all the query methods used in the project. Corresponds to the data entity defined by the Persistencelayer layer. In these word-defined query classes, you can apply any combination of the three query methods provided by Activerrecorder (simple interfaces provided by Activerrecorderbase, simple query SimpleQuery, custom query customerquery). And each of the classes here implements the interface defined by the Idal interface layer.

²dalfactory layer, as the data access factory, through. The reflection mechanism of net calls the related operation in the data access component composed of Idal and Persistencefacade.

²dataaccesslayer temporary layer. It is completely unnecessary to declare this layer first. Because we can not write any SQL statements in the project. All SQL is replaced with HQL. This layer is designed to allow for the technical transition of people in the project team. This layer can operate the database through SQL (not recommended). This layer will no longer be available when the architecture is stable.

Application framework Layer (framework)

The purpose of this layer is technical precipitation. Moving things that are common between projects into the application framework layer to achieve code reuse. This layer can be black-boxed later. can include generic components.

²framework: Accumulate some methods and controls that can be abstracted

²MSMQMESSAG: Implementation of the message processing queue

²pager: Universal Flip Class

²report: General report Class

²controls: Control processing class

²dataformat: Data Format conversion class

²webui: Page Processing class

²validate: Data Check

²object: Conversion and access between objects

5 Benefits of Tiered architecture

1, the developer can only focus on the entire structure of one of the layers;

2, can easily use the new implementation to change the original level of implementation;

3. Can reduce the dependence between layer and layer;

4, in favor of standardization;

5, facilitate the reuse of the logic of each layer.

In summary, layered design can achieve the following objectives: Decentralized attention, loose coupling, logical multiplexing, and standard definitions.

A good layered structure can make the developer's Division of labor more explicit. Once the interfaces between the various levels are defined, developers who are responsible for different logic designs can distract and go hand in hand. For example, UI staff only need to consider the user interface experience and operation, the domain designer can focus only on the design of business logic, and database designers do not have to be cumbersome user interaction and headache. Each developer's task is confirmed and development progress can be improved quickly.

The benefits of loose coupling are obvious. If a system does not have a hierarchy, then the respective logic is tightly intertwined, interdependent with each other, who can not be replaced. Once the change occurs, the reaching, the impact on the project is extremely serious. Reducing the dependency between layers and layers can not only guarantee the future scalability, but also have obvious advantages in reusability. Once each function module has a unified interface defined, it can be called by each module without having to develop the same functionality repeatedly.

The standard is also essential for the design of a good layered structure. Only on the basis of a certain degree of standardization, the system is extensible, replaceable. The communication between layers and layers must also ensure the standardization of interfaces.

"Gold is no can't pure, nobody is perfect", the layered structure also inevitably has some defects:

1, reduce the performance of the system. This is self-evident. Without a tiered structure, many businesses can access the database directly to get the data, and now they have to do it through the middle tier.

2. Sometimes cascade changes are caused. This kind of modification is especially reflected in the top-down direction. If you need to add a feature in the presentation layer to ensure that the design conforms to the layered structure, you may need to add code to the appropriate business logic layer and the data access layer.

6 Software Architecture View

Philippe Kruchten wrote in his book, "An introduction to the rational unification process":

An architectural view is a simplified description of a system that is seen from a certain perspective or point, and describes a particular aspect of the system and omits entities unrelated to this aspect.

In other words, the architecture to cover a lot of content and decision-making, beyond the human brain "overnight" capabilities, so the "divide and conquer" approach from different perspectives to design, but also for the understanding of software architecture, communication and archiving to provide convenience.

　　

Figure 4 4+1 View method presented by Philippe Kruchten

The different architectural views of this approach carry different architectural design decisions, supporting different goals and uses:

L Logical View: When adopting an object-oriented design approach, the logical view is the object model.

L Development View: Describes the static organization of software in the development environment.

L Processing Views: Describes the concurrency and synchronization aspects of the system design.

Physical view: Describes how software is mapped to hardware and reflects the design of the system in terms of distribution.

　　

Figure 5 Architecture design for different requirements using the 4+1 view method

Logical view. The logical view focuses on features that include not only user-visible features, but also "accessibility modules" that must be provided to implement user functionality, such as logical layers, functional modules, and so on.

Development view. The development view focuses on packages, including not only the source programs to be written, but also the third-party SDKs and out-of-the-box frameworks that can be used directly, the class library, and the system software or middleware that the developed system will run on. There may be some mapping between the development view and the logical view: for example, the logical layer typically maps to multiple packages, and so on.

Process the view. Processing views focus on the runtime concepts of processes, threads, objects, and related concurrency, synchronization, communication, and so on. Dealing with the relationship between the view and the development view: The development view typically focuses on the static dependencies of the package at compile time, and these programs behave as objects, threads, processes, and the interaction of these runtime units is the focus of the processing view.

Physical view. The physical view focuses on how the target program and its dependent runtime and system software are ultimately installed or deployed to the physical machine, and how the machines and networks are deployed to meet the reliability and scalability requirements of the software system. Relationship between physical and processing views: processing views pay particular attention to the dynamic execution of the target program, while the physical view attaches importance to the static location of the target program; The physical view is an architectural view that takes into account the interaction between the software system and the entire IT system.

Architecture Summary of Software