Layer-5 logical Architecture Design

Layer-5 logical Architecture Design
Logic: Logical
Physical: Physical
Architecture: Architecture
Framework: Framework
Presentation Layer: Presentation
User Interface: User Interface
Business Logic: Business Logic
Data Access
Data and Storage Management: Data and Storage Management
Graphical User Interface: Graphical User Interface
Fat Client: Richer Client-side
Smart Client: Smart Client
Application: Application
Server control: Server-side control
Event-driven
Reusable component: Reusable component
User Control: User Control
Metadata-driven: Metadata-driven
Object-relational ing

This article will discuss the program design of the layer-5 logical architecture. Once this type of architecture is successfully established, it can be configured to apply to a variety of physical architectures, so as to provide the best service for Windows Forms, Web forms, and Web services.

This architecture is composed of the five parts shown in figure 1 (Note: if the image cannot be sent up, Chinese characters are entered ):

Presentation Layer
User Interface
Business Logic
Data Access
Data and storage management

Figure1.Layer-5 logic architecture

It should always be remembered that the advantage of using the N-layer logical architecture is to clearly divide functions into roles or groups to improve program readability and maintainability. Next we will carefully define the functions of these layers.

Presentation Layer

First, you may be wondering why I have separated the presentation layer from the user interface layer. Indeed, from the perspective of Windows applications, the presentation layer and user interface are the same: they are all graphical user interfaces that can interact with users.

However, from the perspective of Web programs (or from a terminal-based program), the difference should be obvious. Typically, a browser only displays content to users and collects user input information. In this case, all the actual interaction logic-generating content output or analyzing user input code-is run on the Web server (or in the main framework ), instead of on the client machine.

Of course, in the real environment, the browser may run JavaScript scripts or fat client code. However, these codes are untrusted (Annotation: Can be associated with client Form Verification ). These codes must be considered as independent code that interacts with the code running on the server. Therefore, even if some code runs in a browser, the user interface code of your application still runs on the Web server.

It should be noted that the logic architecture currently discussed must support both Smart Clients and Web-based clients (or even more restricted clients, such as mobile phones or other mobile devices ), in many cases, it is important to realize that the presentation layer must be physically separated from the user interface logic. In order to achieve this separation, it is necessary to design the program around this topic.

Note:

There are many technical types in the presentation layer, and each of them will be accompanied by a new, incompatible, and necessary technology. In fact, it is impossible to create a program framework that is completely abstracted from the presentation layer. Because of this, frameworks and frameworks only support different performance layers, rather than automatically creating them. Therefore, we will focus on the other layers in the simplified architecture. The technology in these layers is relatively stable.

User Interface

I have already talked about the differences between the presentation layer and the user interface, so the purpose of the latter should be clear now. The program logic at this layer determines what the user sees, the navigation path, and how to process the user's input. In a Windows application, these are codes placed after the form. In fact, these are also the code that is placed after the form in the Web application. However, in this case, the user interface layer also contains the code in the server-side control. Logically, this is a different part of the same layer.

In many applications, the user interface code is very complex. First, it must respond to user non-streamlined requests (it is difficult to control whether the user clicks the control to enter or exit a form or page ). The user interface code must also logically interact with the business layer to verify user input, execute any tasks that need to be performed, or perform any functions related to the business layer.

Basically, the purpose of the user interface layer is to write code that accepts user input and then provides the input information to the business logic layer, these user input information is verified, processed, or subjected to any other operations in the business logic layer. The user interface layer must respond to user requests and display the results of interaction with the business logic layer. Is the value entered by the user correct? If it is incorrect, what is the exception? And so on.

In. Net, user interfaces are almost always event-driven. Windows Forms always correspond to events when users enter or click form items, and Web forms always respond to events in a client/server round-trip of a user action. Despite the extensive use of object-oriented design in Windows Forms and Web forms technologies, the typical code written on the user interface is not object-oriented, but event-driven.

This means that creating a framework that supports some types of user interfaces and reusable components is very valuable. When creating a Window form user interface, developers can use inheritance and other object-oriented technologies to simplify the creation of the form. When creating a Web form user interface, developers can use ASP. NET user controls and custom server controls to provide reusable components to simplify page development.

Business Logic

The business logic layer includes all business rules, data verification, operations, processing, and application security. Microsoft defines the business logic layer as follows: the business logic layer is a set of business operations of enterprises, these operations include user input verification, logon verification, database query, commercial terms, and conversion algorithms.

 

Note:

Again, when you perform a user verification, if the verification code runs on a browser or an external client, the code is untrusted. You must put these programs in the business logic layer that you can control for implementation, because only in this way can be truly verified.

 

The business logic must be placed in an independent layer completely separated from the user interface code. Sometimes, you may want to copy some code from the business logic layer to the user interface layer to provide a better user experience. However, the business logic layer must implement all business rules, it is the key to centralized management and maintenance.

 

I believe that if you want to achieve a better maintainability and reusability, the separation of this business logic from the features at the user interface layer is absolutely critical. This is because any business logic written to the user interface layer exists in a special user interface code, so that it cannot be applied to new user interfaces created in the future.

 

Writing business logic code in the Windows Forms user interface is meaningless for Web forms programs or Web services and must be rewritten once. This undoubtedly leads to a nightmare of repetitive code. The separation of the two layers can be achieved by clearly defining the program model, object-oriented design, and conversion technology.

 

In a typical application, it is important to realize that business logic will be used in many ways. Most applications perform some user interaction, for example, some forms that provide user input or display content. Many applications also have processes that do not require interaction at all, such as developing tables, distributing property lists, or calculating tax rates.

Ideally, the business logic layer has rich interaction functions when users send data directly to applications. For example, when a user is accessing an order, he expects that the correct data such as the calculation of the tax rate and the total price of the order will be displayed immediately when he inputs the order. This implies that from a physical perspective, the business logic layer may be deployed on the client workstation or Web server to meet advanced user interaction needs.

To support non-interactive processes, the business logic layer is often deployed on an application server that is as close as possible to the database server. For example, the calculation of insurance fees requires a large number of database queries and processing with a small amount of complex business rules. This is what happens to the user's monitor on the server.

Fortunately, deploying a logical layer on multiple physical layers is possible. Doing this requires a long term plan and technical design. However, the final result is a separate deployment on the client workstation (or Web Server) and independent business logic layer on the application server. This enables the application to provide an advanced user interaction experience and efficient processing of non-interactive operations when users directly talk to the application.

Data Access

The code at the data access layer interacts with the data management layer to obtain, insert, update, and move data. The data access layer does not actually manage or store data. It only provides an interface between the business logic layer and the database.

Just as the reason why the presentation layer is separated from the user interface layer, the data access layer has its own logic. In some cases, the data access layer is placed on a machine, which is different from the machine running the user interface or (and) the business logic layer. In other cases, the data access layer may be placed on the same machine as the user interface or (and) business logic layer to improve performance and fault tolerance.

Note:

Putting the data access layer and business logic layer on the same machine may improve fault tolerance. It may sound strange, but consider Web forms, in this case, each Web server is the same for other servers. Place the data access layer code on all Web servers to generate automatic redundancy at the data access layer, business logic layer, and user interface layer.

Adding a physical layer only for data access will make it difficult to implement fault tolerance, because it increases the number of layers for implementing data redundancy. There is also a negative effect. Adding more physical layers will also reduce the running speed of a single user, so this is not important.

Logically, an independent data access layer is defined to separate the business logic from any interaction between the database (or any other data source. This separation provides great flexibility for whether to run the data access code in the current system or other new systems in the future. It also makes it easy to replace a data source without changing the application. This is very important, because in some cases it makes it easy to switch from one database to another.

Another reason for this separation is that Microsoft is used to changing the Data Access Technology every three years, this means that you need to re-write the data access code to follow the trend (think back to DAO, RDO, ADO 1.0, ADO2.0, and the current ADO.. NET ). By separating the data access layer code into an independent layer, the impact of this change is limited to a very small scope of the application.

Typically, the data access mechanism is implemented in the form of a series of services. Each Service is a separate function called by the business logic layer for data acquisition, insertion, and update. Although these services are usually created as objects, it is important to realize that an efficient data access layer should be very streamlined. Using as many object-oriented designs as possible for access to a relational database often results in higher Program Complexity and lower execution efficiency.

I think the best way to implement the data access layer is to write a series of methods, but encapsulate these methods in an object so that they can be better organized.

Note:

If you are using an object-oriented database instead of a relational database, the data access code should be very object-oriented. However, few people have this opportunity, because almost all data is stored in relational databases.

In some cases, the data access layer can be very simple. It is only composed of a series of methods that use ADO. NET to directly obtain or store data. In other cases, the data access layer is much more complex and provides more abstract or even metadata-driven methods to obtain data. In these cases, the data access layer contains a large amount of complex code to provide a more abstract data access mode.

Another role that the data access layer often plays is to provide the ing between the object-oriented business logic and the data stored in the database. A good object-oriented model is almost never the same as a good relational database model. Objects often contain data from multiple tables or even multiple databases. The process of extracting data from a relational model table and providing it to the object-oriented model is called object relational ing (ORM ).

Data storage and management

Finally, there is data storage and management. Database servers like SQL Server and Oracle usually assume such roles, but gradually, other applications may provide the same functions through technologies like Web Services.

The core of this layer is that it physically creates, acquires, updates, and deletes data. This is different from the data access layer. The data access layer only initiates a request to create, retrieve, update, and delete data. The data management layer actually performs these operations on databases and disk files.

The business logic layer (through the data access layer) calls the data management layer, but this layer often contains additional logic to verify the correctness of the data and their relationships with other data. Most of the time, this is from the real Relational Data Model on the database side, and sometimes it is from the business logic rules of external applications. This means that a typical data management layer should also include the business rules implemented at the business logic layer. In this case, replication is inevitable, because relational databases are designed to enforce the integrity of the relationship. This is just another form of business logic.

In general, whether you use stored procedures in SQL Server or use Web services to call another application, data storage and management are handled by a series of services and stored procedures that can be called as needed. Just like the data access layer, the design of data storage and management layer is very streamlined (:Streamline is more important than object-oriented.

Table 1.Role played by layer-5 logical layer

Layer	Role
Presentation Layer	Displays and collects user input.
User Interface	As an intermediary between the user and the business logic, get the user input and provide it to the business logic layer, and return the result to the user.
Business Logic	Provides all business rules, data verification, operations, processing, and application security
Data Access	Serves as an intermediary between the business logic layer and the data management layer. It also encapsulates all the data access technologies needed (such as ADO. NET)
Data storage and management	Create, obtain, update, and delete data physically, and maintain the data.