The software architecture style is the usual mode to describe the system organization mode in a specific application field, and the hierarchical system style is one of them, this article describes a hierarchical system architecture solution applicable to B/S and C/S hybrid scenarios.
I. Layered Architecture
The entire system can be divided into seven layers: storage layer, protocol layer, implementation layer, injection layer, Web display application layer, Web Service Application layer, and client application layer. The storage layer generally corresponds to relational databases, the remaining six layers are our focus.
Figure 1: layered architecture Diagram
Taking the system as a solution, we can see that this solution mainly includes the following nine development projects ):
- Demo. Core: the Core Assembly, including the business logic interface, data access interface, and entity class;
- Demo. Managers: specific implementation of the business logic layer;
- Demo. daos: specific implementation of the data access layer, which can be further subdivided according to the database type if necessary;
- Demo. IOC: Implementation of dependency injection. Spring. NET is recommended, and the factory mode can also be introduced for reflection;
- Demo. controllers: the Controller corresponding to the Web interface is designed based on the MVC idea to provide support for Ajax interaction. The soap method is not recommended;
- Demo. webui: the browser interface, including HTML, CSS, JS, and images, follows the unified interface specifications;
- Demo. WebService: a Web Service released externally for the client or other applications. It is recommended to use the soap method and can encapsulate the WCF Service for. Net callers;
- Demo. serviceproxy: Web Service proxy, which encapsulates the call of Web Service by implementing the business logic interface. It is a special case of the Implementation Layer and can be directly referenced by the client or other applications;
- Demo. clientui: PC Client user interface. Similarly, demo. mobileui can be introduced as a mobile client.
Unit tests are not included in the above-mentioned architecture. You should add another demo in actual applications. unittest Development Project, which is applicable to the demo. the interfaces defined in core are used to compile test cases. These test cases are used as demos. managers, demo. the acceptance criteria of the specific interface implementation class of the daos project.
Ii. Compile Dependencies
There is a certain compilation dependency between the nine development projects involved in "layered architecture", as shown in. The arrows indicate dependencies:
Figure 2: Compile Dependency Graph
Demo. core does not depend on other projects; demo. managers, demo. daos, demo. IOC depends on demo. core; demo. controllers, demo. webService depends on demo. core and demo. IOC; demo. webui depends on demo. controllers; demo. serviceproxy needs to add demo. the reference of Web Services in WebService is not a compilation dependency, so it is expressed as a dotted line; demo. clientui depends on demo. core and demo. IOC.
In addition, demo. webui, demo. demo is required for normal running of WebService. managers and demo. daos support, demo. demo is required for normal operation of clientui. serviceproxy support. This support will be configured in IOC mode, so there is no compilation dependency.
3. Application Publishing
The web presentation application layer, Web Service Application layer, and client application layer can be collectively referred to as the application layer. Therefore, there are three instances in the application Publisher: web site, Web Service site, and client program, and the first two can be combined into one.
Figure 3: Application release diagram
Iv. External Reference
During application system development, the reference to external assembly is a typical phenomenon. Here, it is summarized into three types: Implementation-layer auxiliary tools, Business Logic Routing, and plane-oriented additional tools.
- Implementation-layer auxiliary tools: Spring. Data or Hibernate is introduced to the data access layer (Demo. daos) to process data access.
- Business Logic Routing: if the system uses the LDAP user library directly, you can add an adapter that implements the business logic interface and forward the user request to the LDAP server for processing.
- Aspect-Oriented addition: AOP. If the system needs to add the logging function to record all business logic operations, you can add a service logic interface implementation class (agentmanager ), this class holds the reference of another interface implementation class (realmanager). agentmanager does not actually implement the method required by the interface, but transfers it to realmanager for processing. Before and after the transfer, you can add the log record code.
5. Architecture Evolution
In some cases, we may need to cache some data locally on the client, in this case, the client program will contain real business logic and data access functions (the service request involved in the client is forwarded by the Service proxy to the Web Service for processing), and the client application layer architecture will evolve into a structure.
Figure 4 client evolution Diagram
The storage layer generally uses a file-level database (such as SQLite). The protocol layer, injection layer, Implementation Layer demo. Managers, and demo. daos are common projects. The injection layer controls the injection of the remote processing logic (Demo. serviceproxy) and local processing logic at the same time. The demo. clientui can be freely selected as needed, or you can directly create a business logic adapter to implement automatic routing.
Vi. Conclusion
This article aims to describe a loosely coupled Architecture Scheme. The guiding ideology is interface-oriented, Producer/consumer mode. The protocol layer defines the interface as the core standard, and the Implementation Layer is positioned as the producer, the application layer is the consumer. In practical applications, the development projects involved above can be moderately merged or split.