[Reprinted] Application System Architecture Design

Application System Architecture Design

On the surface, we are developing a variety of different applications. In fact, the corresponding architecture design is relatively stable. Programming in a good architecture is not only a pleasing thing for developers, but more importantly, the software can show a healthy posture. The architecture design is unreasonable, not only do developers suffer, but the life cycle of the software itself is even more under severe threat. Here I will give a rough discussion of the general architecture Process Design of the Application Development System on the Microsoft DOTNET platform.

Overall Design Drawing

 

Presentation Layer

The presentation layer consists of the UI (User Interface) and UI control logic.

LUI (User Interface)

The UI is the user interface of the client. It receives commands, requests, and data from the user, passes them to the business layer for processing, and then presents the results. Based on different clients, we generally divide the applications into BS (browser-server) browser structure and CS (client-server) Desktop client structure.

The advantage of BS is that you do not have to worry about the client. You only need to deploy and maintain the server. The advantage of CS is its powerful interface interaction and expression capabilities. Rich Internet application (RIA) is a technology that integrates the advantages of these two structures, it relies on the one-time installation of a universal interpreter on the client to obtain powerful interface interaction and convenience without the need to deploy a specific client. There are many specific implementation technologies, such as Microsoft's smartclient, avron; Macromedia's flex; js-based bindows; Ajax and so on.

LUI control logic

The UI control logic is responsible for processing data interaction between the UI and the business layer, controlling the state process between the UI and simple data verification and formatting functions. Specifically, in the DOTNET event-driven programming model, the UI control logic is naturally implemented in event functions, such as pageload event functions and buttonclick event functions. Among these event functions, the main task is to exchange and call the data between the UI control and the business entity. However, in the face of a large amount of data exchange workload and maintenance workload, it becomes the biggest problem. In a complex application system, state and process management must be considered. They are also part of the business logic, if it is written directly in the event function without being encapsulated, the business will depend on the presentation layer. The two questions are discussed below.

1. Data Interaction Between the UI and business entities

The business entity responsible for data exchange in this phase is called DTO (data transfer object). When processing input, we enter DTO In the UI control and then spread it down, when processing the output, the user sends a request to the business layer to return the data in DTO format and then assign it to the UI control for display. Therefore, we need a way to automatically solve the problem of round-trip assignment. Unfortunately, although many controls in DOTNET support data binding, there is still no complete solution. We can design an adapter to automatically handle such binding according to a certain ing relationship. This ing relationship is preferably the prior naming convention between the UI control and the DTO attribute, the conventions in this way can be implemented as mappings without adding any configuration files or configuration work.

2. Status and process management

Since it is part of the business logic, it should not be coupled to the presentation layer. The Model-View-controller mode provides methods to achieve this goal. Controller is the core of the entire solution. It is a process manager. All the commands and data from the UI are distributed to the business layer or other UIS through the Controller, so that we can process the process, permissions and other logic are encapsulated separately, such as in the configuration file to maximize service reuse. The MVC solution in DOTNET does not have as many options as in Java. Currently, the following options are available:

Microsoft's uipab can handle process jumps under BS and CS, so that the same business system can have different presentation methods for webform and winform.

The open-source mavrick. NET is only applicable to ASP. NET applications. It provides good support for processes, internationalization, page packaging, and XSLT page conversion.

The open-source lattis is also applicable only to ASP. NET applications.

Business Layer

The business layer encapsulates the actual business logic, including data verification, transaction processing, permission processing, and other business-related operations. It is the core of the entire application system. Therefore, it is necessary to design a business layer that truly reflects the actual needs. We divide the actual business into two parts: business data and business operations.

LBusiness Data

Business data is the core of the business logic. The final business data will be displayed in a fixed format in the memory, transmitted between different levels of the system, and act as the DTO role. Business data can be expressed in two ways: Table model and domain model.

Table model directly maps tables in the database into business data objects. This advantage is suitable for machine operations and ADO. net directly provides convenience for such operations, but it is not intuitive to express complex business relationships. It is only suitable for quick development where the business needs correspond directly to data tables. Generally, dataset or strong-type dataset (strong Typed Dataset) are used. Strong-type dataset supports type check during compilation, which is more efficient than normal dataset. Dataset has many convenient features: you do not need to write maintenance classes by yourself. It supports serialization, data copy storage, data collection, and control binding, microsoft provides corresponding generation tools and persistent solutions. However, the disadvantage is obvious. complex data is not intuitive. As DTO is transmitted across all layers, especially in distributed environments, the large volume and relatively slow instantiation put a great deal of pressure on performance.

Domain model is modeled based on the actual business in a realistic way using OO ideas, which is suitable for complex business systems. It is usually expressed in the form of custom data entities. Custom Data entities have good performance. The type check during compilation has the advantages of intuitive data presentation in line with actual business operations. However, you need to define your own maintenance classes, in a distributed environment, you must compile your own serialization method.

Considering a variety of factors, although the business is simple, it is inevitable that the system will not become more complex in the future because of the high efficiency and scalability of table model modeling, in terms of performance, it is better to use domain model modeling.

LBusiness Operations

Business Operations are responsible for processing business data, such as verification, flow direction, integration, transactions, and permissions. However, they are not responsible for operations on data sources. There are two ways to design the relationship between it and business data.

Separates business data from business operations and encapsulates business data into data classes that only contain get and set data. This data class only acts as DTO. Encapsulate business operations into independent service classes and act as the business layer together with business data. In this way, the system is simple and intuitive when it is not complex. As the system becomes increasingly complex, Service Classes become messy, separating tightly coupled data from operations is also a negative factor for reuse. For details, refer to Martin Fowler's anemia domain model, but I don't want to directly access the data source at the business layer.

Integrates business data and business operations, encapsulates business data and related business operations, and is called a business entity. The business entity acts as a unified business layer to provide services for the presentation layer, at the same time, I am also responsible for DTO transmission across all layers. I prefer this complete domain model design method. Every business entity can exist as a separate component, it has great benefits for componentized multiplexing.

LDependencies between business modules

Dependencies between business modules are sometimes difficult to solve, especially some reusable business components, such as permission management and email sending. Managing these different business components is our goal. The IOC container provides us with the most perfect solution, by injecting different modules into the system, we can call this component without knowing its existence. However, there is only one choice for immature spring. net. We only have to sigh, so we will not discuss it much.

Business Data access layer

The business data access layer is an exclusive layer for specific application systems. It provides the minimum operation mode for the business layer to interact with data sources. It is only the data access interface required by the business layer, the business layer relies entirely on the services provided by the business data access layer. These services receive data from the business layer or return to the business entity, which shields the differences between actual business data and machine storage methods. Of course, the data layer can achieve this by selecting an abstract solution, but the biggest feature of the business data access layer is to abstract specific businesses, the abstract data layer access scheme is abstracted for general purposes. The specific design in the business tends to become more powerful, so that we can maximize the reusability of the Upper-Layer Code. If you need to change the storage policy, if the access to the data layer is too different, when changing the data layer cannot solve the problem, we only need to change the business data access layer at most, without changing the business layer.

The business data access layer consists of the DaO (Data Access Object) layer and the system service layer. The Dao layer provides the most basic data access services for each business entity, and the system service layer provides general data access services with little business relationships for the system, the two layers are at the same level in the system.

Relationship between business layer and business data access layer

Data Layer

The purpose of the data layer is to provide an interface for external access to the data source, we should choose an abstract data access interface that provides data source independence and access the data layer components of the data source by attaching different dataproviador to it, this facilitates transplantation to different data sources. There are currently three data layer solutions:

1. encapsulate ADO. net

These Data Access Components are based on ADO. net, which has the advantages of low encapsulation layers and the fastest speed. We can manually organize SQL statements to adapt to complicated operations and personalized optimization. The disadvantage is that you cannot directly process the business entity objects in the Custom Data entity mode. You need to pass the data attributes in the business entity as parameters. Although this method is the safest, development efficiency, quality, maintenance, and secondary development become particularly prominent as the system grows, developers are increasingly demanding. In addition, the encapsulation of transaction operations is not very good, and declarative transactions cannot be provided. Therefore, access to the data layer is often required at the business layer. Such components are currently widely used, such as the Data Access Application Block provided by Microsoft in enterpriselibrary and the previous daab3.1. Enterpriselibrary is a mature product, including data access, exceptions, logs, cache, encryption, configuration, security, and other components.

2. 2. Or-mapping component

Orm is the best data persistence solution. It has the advantage that it can manipulate data in an object-oriented manner, so it can directly process the Business Objects of custom data entities, we don't have to worry about SQL statements and underlying storage methods at all. This greatly simplifies the code to improve the development efficiency and greatly facilitate the maintenance and expansion in the future. The disadvantage is that the underlying layer is shielded so that we cannot optimize specific data sources. In addition, the SQL operations for complex association are not powerful, and the performance is also poor, but the cache performance is much better, the biggest problem with DOTNET is that there is no mature and cheap ORM product for us to use, all of which are beta and commercial versions. These versions have more or less problems, so the real application needs to be carefully examined. There are many examples, such as nhib.pdf, gentle. net, xpo, and Grove. net.

3. datamapper (sqlmapper)

Sqlmapper provides a compromise for the above two methods. It can directly process the Business Objects of custom data entities in an object-oriented manner, at the same time, you can execute a handwritten SQL statement based on the ing between the data source and the business entity, so that we can optimize the specific data source and be competent for complex operations. Currently, only ibatis. Net is a product. It is an open-source project moved from Java to which Dao can be replaced without compilation.

So far, the entire architecture solution has been discussed. We can see that the solutions available under DOTNET are so limited. In contrast, we look at the Java World, there are so many mature component frameworks available for use, drool... however, DOTNET is also maturing and we need time to wait. This architectural design concept only represents my personal understanding, and does not mean that all development is such a set of solutions, and specific adjustments need to be made in specific environments. It is expected to play a leading role. My email address is I-Simon at msn.com. Due to my experience, I am not familiar with it. If you have any incorrect or insufficient information, please let me know. In addition, this article will be updated continuously based on the latest technological advances.