N-tier architecture and tips

This is a file translated from codeproject's previous article about the n-tier architecture. I feel that it is well written, especially a basic concept. It is very thorough and translated for sharing.

Source: http://www.codeproject.com/Articles/430014/N-Tier-Architecture-and-Tips

Overview

The N-tier architecture is an industry-recognized software development architecture model. It is suitable for enterprise-level C/S applications to solve problems such as scalability, security, and fault tolerance of applications. There are many tools and features in. Net to implement the n-tier architecture, but this does not mean that. Net is a predefined platform for implementing the n-tier architecture. Therefore, in order to be able to design and implement a good n-tier architecture application, it is very important to fully understand the concept of. net. However, many people who have been familiar with or have been using n-tier for many years still cannot understand the concept.

This article will try to clarify some basic concepts of N-tier from various aspects and provide some practical skills. The premise of these practical skills is to assume that the Team has control over all layers in the n-tier architecture. Another article uses. Net to describe the n-tier architecture example: An-tier architecture sample with ASP. NET mvc3, WCF and Entity Framework.

Introduction to n-tier architecture

Terminology differentiation and Connection

Tier and Layer

First, we need to clarify the two concepts tier and layer Used in the n-tier architecture.

A tier usually represents a physical deployment host. A server that runs independently is a tier. Several servers may also be considered as a tier, such as a Service Fault-Tolerant cluster. Comparatively speaking, layer generally means logical software components that are differentiated by functions. layer is used for software development purposes. The implementation of layer software has many advantages. It is a good way to implement the n-tier architecture. The layer and tier may not necessarily match each other. A layer can run on an opposite tier, and multiple layers can also run on the same tier.

A layer may also run on multiple tier. For example, in Figure 2 provided later in this article, the persistent layer is in. net contains two parts: the persistent Library and the WCF data service. The persistent library in the persistent layer runs in the same process together with the business layer, the cause is that the persistent Library acts as an adapter for the business layer to access the WCF data service. However, the WCF data service in the persistent layer runs on a separate independent tier.

Another example: we can strip the data validation in the business layer to form an independent database (the database is still in the business layer ). This library can be directly called by the persistent layer of the client to improve the client interaction. The Data Validation Part of the business layer runs in the same process as the client persistent layer, and the other part of the business layer runs in another process.

Tier and Process

If a layer can run in an independent process. Generally, it can run on an independent host (Tier). Therefore, in the n-tier architecture, it is considered as an independent tier. However, this conclusion is not necessarily true. For example, if two layers are designed to run in two independent processes, they communicate with each other. If they are using non-distributed IPC communication, such as local shared memory, the two processes can only run on the same host, unless the communication between them uses distributed IPC (such as socket) communication, these two layers can be considered as two independent tier.

Layer and Process

A layer can run in an independent process, several layers can also run in the same process, and one layer can run in several processes.

3-tier architecture

First, we will introduce the concept in 3-tier. The simplest N-tier architecture is a 3-tier architecture with three layers: presentation layer, application layer, and data layer, as shown in 1:

A layer can only directly access the public components of a layer located under it. For example, a layer can only access public components in the application layer, but cannot access public components in the orientation data layer. An application layer can only access public components in the data layer. You cannot access the public components in the presentation layer.

This can minimize the dependencies between layers. The minimal dependency will benefit the development, maintenance, design, system resizing, and other methods. It can also achieve as much security control as possible. For example, the client layer cannot directly access the data layer and can only access the application layer. Therefore, the data layer can complete a higher level of security control.

In the end, the dependency between software components can be avoided.

To declare a complete 3-tier architecture, all three layers should run on an independent host.

Figure 1: 3-tier architecture

The description of Layer 3 is as follows:

Display layer: users can directly access this layer, such as desktop UI and web pages. This layer can also be called a client.

Application Layer: This layer encapsulates business logic (such as business rules and data verification), domain concepts, and data access logic. This layer can also be called an intermediate layer.

Data Layer: an extended data source that stores application data, such as DB servers, CRM systems, ERP systems, mainframes, and other legacy systems. We often see dB servers. In the n-tier architecture, we need to use non-embedded database systems, such as MySQL, SQL Server, DB2, Oracle, or PostgreSQL. Non-embedded database systems can run on an independent host. Embedded databases such as MS Access and DBASE cannot run on an independent host. Therefore, it cannot be used as a data layer in the n-tier architecture.

1, 2, 3, or N-tier architecture

1-tier

All layers can only run on the same host. To implement the 1-tier architecture, we need to adopt an embedded database system because such a database system cannot run on an independent process. Otherwise, this is a 2-tier architecture, because non-embedded database systems can usually run on an independent host (Tier.

2-tier

The display layer and application layer run on the same host. Alternatively, the application layer and data layer run on the same host. The entire application system cannot run on more than two hosts.

3-tier

The simplest case of the N-tier architecture is that three layers run on an independent host. In fact, these three layers can also be deployed on the same host (3-tier architecture application, deployed as a 1-tier system ).

N-tier

N> = 3 can be called the n-tier architecture. A typical N-tier architecture is described in figure 2. Layers in the 3-tier architecture are not separated into multiple layers. The separated layers can also run in multiple tier. For example, an application layer can be divided into business layer, persistent layer, or even more. The presentation layer can be divided into the client layer and the client performance layer. In Figure 2, to illustrate a complete N-tier architecture, the client performance layer, business layer, and data layer run on three independent hosts (Tier) respectively. Same as 3-tier, all layers can be deployed on the same host (Tier.

Figure 2: N-tier architecture
Summary of the layers in Figure 2:
Client layer: This layer can be directly used by users. There are several clients that coexist, such as WPF, Windows form, and HTML web pages.
Client presenter layer: contains the presentation logic required by the client. For example, music videos in ASP. NET and IIS web servers. It is also an adapter for different clients to access the business layer.
Business Layer: Processes and encapsulates all business models and logic, also known as domain layer.
Persistence Layer: reads and writes business data on the data layer. It is also called the data access layer (DAL ).
Data Layer: extended data source, such as a database system.
Sometimes, the number of tier is greater than or equal to 3, but the client display layer, business layer, and data layer cannot run on an independent host (Tier) separately. Is this an N-tier architecture? We define it as a non-completely n-tier architecture because the client presentation layer, business layer, and data layer cannot run on an independent host (Tier) separately.
If we use modern non-embedded databases such as SQL Server and Oracle, the database system can run on an independent host. Therefore, in the case given in Figure 1, in the standard 2-tier architecture, the presentation layer and application layer can only run on the same host. In the Standard 3-tier architecture, the presentation layer and application layer run on one host respectively; A complete N-tier architecture is consistent with the standards of the 3-tier architecture.

Advantages and disadvantages of Tier Architecture

1 or 2-tier

Advantages

It is suitable for low-user systems with a small amount of processes and tier. The architecture is simple. Low costs in hardware, network, maintenance, and deployment.

Disadvantages

When the number of users in the system increases, problems may occur. problems such as security, scalability, and fault tolerance may occur.

IER Architecture

N-tier architecture

Advantages

1. Scalability: decoupling between multi-tier deployment and tier deployment brings about good system scalability. For example, data tier is extended through the database cluster without involving other tier transformations. The Web client can be expanded through the Server Load balancer without affecting other tier services. Windows servers can easily perform load balancing and fault migration through clusters. In addition, the business tier can also expand its applications through clusters, such as the Weblogic cluster in J2EE.
2. Better and more convenient Security Control for the entire system: if each tier has different security requirements, we can implement different security control for each tier. For example, the business tier and data tier have a higher security level than the display tier, so we can place the business tier and data tier within the firewall. The 1-2 tier architecture cannot be deployed due to its tier restrictions. Similarly, for the n-tier architecture, users cannot directly access the business layer and data layer. All user requests must be forwarded to the business layer by the client display layer, and then the data layer is submitted. Therefore, the client display layer is more like a proxy of the business layer, and the business layer is a proxy of the data layer. These similar proxy layers provide better protection measures for the layer they represent.
3. Better Fault Tolerance capabilities: for example, the database system in the data layer can obtain better fault tolerance and load balancing capabilities through the cluster without affecting other layers.
4. you can perform logon tier upgrade and update without affecting other layers: In the OO development mode, the implementation mode of interface dependency can decouple all layers, then, each layer can be changed independently without affecting other layers. Interface dependency means that a layer only depends on the Interface of another layer, rather than its implementation class. Similarly, the dependence on the existence of directly adjacent lower layers minimizes the impact of a layer Change on the entire system. For example, to keep the interface unchanged, We can independently update or replace the implementation of any layer without affecting the system.
Due to changes in technology and business needs, it is common to update a layer into another implementation. For example, we mainly use Windows form first, and now we mainly use WPF. If our original system uses the layer decoupling structure, we only need to update the Windows form implementation on the client to the WPF implementation without changing the layer on the server.
5. friendly and efficient development: layer decoupling means that the software logic is divided into different components through functions. The components are friendly and efficient during development. Each layer can be developed by an independent team. This team only needs to know the functional specifications of the layer. A dedicated team can better and more efficiently process related tasks.
6. Maintenance friendliness: the n-tier architecture groups data by functions. All the logic of this case is clear, easy to understand, and easy to manage.
7. friendliness of new feature appending: Due to the decoupling brought by the N-tier architecture and grouping of logical components, new features appending will become easy and will not affect the entire system too much.
8. Better reusability: the low coupling between grouping and layer of logical components makes the system more reusable. Low-coupling component groups can be implemented in a more convenient way, which enables reuse of more applications.

Disadvantages:

1. Because N-tier uses more hosts, networks, and processes, when the hardware and network bandwidth is insufficient, the performance of the entire application will be reduced.
2. More hardware, network, maintenance, and deployment costs.
The performance of applications deployed in the n-tier environment is a self-conflict issue. On the one hand, if the number of users is not high enough, the performance will become low due to too many hosts, processes and networks. That is to say, if the number of users is small, integrating all application logic into a tier or a process will achieve better performance. However, if the number of users increases, the scalability of the N-tier architecture will improve the overall performance. For example, load balancing and database clusters in the n-tier architecture will improve the system performance.

Why is the performance of N-tier different when the number of users is low or high? This is because the bottlenecks of the entire application are different in both cases. The bottleneck of an hourly application is the time spent in inter-process communication. If more hosts, processes, and networks are involved, more time is spent. Therefore, the performance will be reduced. However, when the number of users increases, the capacity of the server (for example, the competition for CPU and memory resources on the same host, the limitation on the database on the server, and the limitation on the processing capability of the Web server) the bottle has been transferred. Only the n-tier architecture can solve these bottlenecks. Generally, Server Load balancer of a server cluster is used to correspond to the scalability of the N-tier architecture. More hosts are used to distribute large user request tasks. This improves the performance. In addition to improving performance through scalability, the N-tier architecture can also improve performance through better hardware and network bandwidth to meet business needs.

Business Data validation in the n-tier architecture

In order to ensure the robustness and integrity of the entire business system, data verification is important and necessary in the n-tier architecture. The first question about data verification is: Which layer or where to implement data verification? There are some rules and facts for this question. You can give us some tips or answer this question:
1. Data verification must be performed on any layer. Generally, the closer the Client layer is, the more efficient the performance is. The more far away from the client layer for verification, the application will have higher reliability and robustness. When the validation is implemented on the business layer or persistent layer. Whether or not the client performs verification can ensure that the data is verified.
2. When we decide which layer to complete the verification, we need to balance the performance, reliability, and robustness. At the same time, we also need to consider the actual situation. If we have control over all layers, we can verify all the clients and clients to improve performance. However, if the business layer is exposed to clients or clients outside our control, whether or not our clients implement verification to ensure reliability and robustness, verification must be performed on the business layer or a lower layer.
3. It is efficient to perform verification in the client test. For example, JavaScript is used on the Web page to complete the verification. However, users can easily bypass client verification, such as page hacking. Therefore, for performance and reliability, verification must be performed on both the client side and the server side. The business layer and other lower layers generally belong to the server. The client display layer can be either on the server or on the client;
A Web Server Client displays a layer where ASP. NET is on the server and WPF is not on the server.
4. A better practice is to complete a simple verification on the client from the perspective of performance, and complete verification on the server from the perspective of reliability.
Simple data verification is mainly used to check the simple attributes of an object instance. Completed data verification includes simple data verification and some complex data verification. Complex data verification includes Class-level data verification that spans multiple attributes in an entity instance, and attribute data verification that spans multiple similar or different types of entities.
5. For some Interactive Client applications, whether or not we perform data verification on the server, we need to complete client-side verification within the acceptable range of interactivity.
Some game applications belong to this type.
6. No matter where data verification is implemented, we should implement and maintain a version of data verification logic in one place. All layers share the verification logic of this version.
Why? The purpose of this operation is to ensure better reusability. It avoids conflicts between source code duplication and verification logic, making development and maintenance easier, and ensures consistency of verification logic throughout the application.
In addition, the verification logic will change with the changes of the business. To maintain the verification logic of a version and ensure its flexibility, you must be able to be flexibly called by any layer as needed.

How to correctly deploy N-tier architecture applications

More tier brings more system complexity, more deployment and maintenance costs and time. Therefore, the number of tier should be limited to the minimum value that is sufficient to solve problems such as scalability, security, and fault tolerance. Do not deploy redundant tier on the basis of solving the required problems.
We usually need at least 3-tier to solve these problems as much as possible. In some cases, if we do not care about these issues, we can select a 1-tier or 2-tier architecture, or deploy the n-tier architecture to the 1/2-tier architecture, to improve the performance.
So what is the optimal number of tier? There is no fixed answer. It depends on our business needs. We need to select the number of tier which is the best balance between the advantages and disadvantages in the n-tier architecture.
We provide two different cases:
A) All layers run on one host process.
B) all layers run on different processes of the same host.
Case 1 is actually a 1-tier architecture
Case 2 is generally an N-tier architecture for 1-tier deployment.
In both cases, although both are deployed on one host, the 1-tier architecture has better performance due to fewer processes involved. Multi-process communication and collaboration are more complex and slow than processes. No matter what IPC communication technology (TCP/IP, named pipe, message queue, or shared memory) is used ), therefore, on a deployed host, we should keep as few application processes as possible to achieve better performance. But how?
The N-tier architecture can be implemented in the following way: you can easily upgrade a certain tier by using the configuration file.
Here is a detailed instance application chapter: An-tier architecture sample with ASP. NET mvc3, WCF and Entity Framework.

In practice, the N-tier architecture is subject to many changes. For example, to achieve better interaction, You need to place the client display layer and business layer in the same process. If you are interested, you can further explore and study this topic on your own.
In addition, the 3-tier architecture can be deployed on a tier of less than or equal to 3. However, a 2-tier architecture cannot be deployed in a 3-tier architecture; otherwise, it should be called a 3-tier architecture.

How to deploy the n-tier architecture through software technology

The main features of N-tier are the ability to deploy one or more layers on different hosts to handle issues such as scalability, security, and fault tolerance; the associated tier must communicate with each other. How are these implemented? When an application runs in a process with an extremely single tier, the communication between the two tier is actually classified as an IPC communication problem. Distributed IPC communication supports cross-host communication between two processes, such as socket and distributed message queue. In essence, these distributed IPC communication methods are capable of supporting N-tier deployment.
For example, if two tier servers use TCP/IP socket for communication, the two tier servers can be deployed on different hosts. In. net, when self-built WCF supports communication between processes on the same or different hosts, WCF can easily deploy N-tier, which is built based on the IPC method. The advantage of deploying N-tier using WCF is that WCF can implement SOA. SOA can achieve loose coupling between layers.

Practical skills in the development of the N-tier architecture

Designing, implementing, deploying, and maintaining an N-tier architecture application is a difficult task. If you do not have a clear idea at the beginning, you may waste time here or where to make a detour. We have already talked about some practical skills on deployment and data validation. Here we will give some practical skills on the development of the N-tier architecture. The premise of these practices is that a team has full control over all layers of the N-tier architecture application.
1. decoupling between layers through some loose coupling technologies, such as soap xml and interfaces. In OO development, each layer only depends on its interface of the next layer directly, rather than its specific class. In this way, we can achieve maximum decoupling between layers, which will bring many benefits to development, unit testing, maintenance, upgrade, layer internal changes, reusability, and so on.
2. Try to use automation tools to maintain a version of the POCO business entity class that can be reused throughout the business system. Why? Business Entity classes are the basis of the N-tier architecture, which transmits information from the top layer to the bottom layer. Today's business applications tend to become larger and larger, so it is very difficult and error-prone to manually create these business entity classes. In particular, some people prefer to use different versions on different layers.
Therefore, we recommend that you use a lightweight version of the entity class generated using automated tools as much as possible throughout the application. This can save a lot of time and eliminate the disadvantages of different version management.
Today, there are many code generation tools available for us to choose from, such as the Entity Framework code generator. Of course, there may be different requirements for entity classes of different layers. We can use system. componentmodel. the annotation function of annotation and the local class in C # are used to restrict and extend the code generator to meet the special needs of the real class on the special layer.
3. Use automated tools or packages to map business entity classes to traditional relational databases (data layers. Modern business systems and data have become increasingly large, and manual ing between them is troublesome and error-prone. There are many tools or packages that can help us do this, such as Entity Framework and nhib.pdf in. net, and hibernate in Java.
4. Use the Code Generator whenever possible to process a large number of similar codes. If you do not find a code generator suitable for your purpose, use the OO development language (such as C #, Java) and XSLT (Extended style sheet conversion language) to develop one by yourself. This is not very difficult. XSLT is an XML-based language that can be well adapted to the processing purposes of code generators, because XSLT can easily convert XML documents into any text documents.
5. The business layer and persistent layer are easily coupled. Pay attention to and avoid this problem. For example, in. net, the WCF Service can directly access the Entity Framework, which is common. However, in this case, the business layer and the persistent layer are tightly coupled. In this case, problems may occur in unit tests, upgrades, and internal changes of the layer. The common solution is to add an adapter between two layers so that you can decouple them through interfaces. For details about the instance, refer to another document: An-tier
Architecture sample with ASP. NET mvc3, WCF and Entity Framework.

6. The presentation layer on the client should form a separate library of the public code used by all clients, so as to maximize the reuse of the surrogate mother.
7. Adding a cache layer to each layer can improve performance. For example, you can use the varnish accelerator, Drupal, or other Web applications in ASP. NET to set the cache layer between the client layer and the client display layer. In PHP applications, memcached and APC cache can be used as caches to cache business data. The request searches for data in the cache. If the data is valid, the request directly uses the data instead of  from other layers. This improves the performance. Note that the old data in the cache should be updated and cleared in a timely manner. In. net 4 namespace system. web. caching can be used as ASP.. Net cache; namespace: system. runtime. caching can also be used as a cache, not just in ASP.. net. Enterprise
The Caching Application Block in the library can also be used as a cache.
8. to adapt to the changing business needs and technologies, it is a good way to easily and flexibly deploy any form of deployment (including 2-tier architecture deployment.
For example, replace and update the tier in the n-tier architecture using the key-Value Pair configuration file. For details about the instance, see the following file: a n-tier architecture sample with ASP. NET mvc3, WCF and Entity Framework.

Conclusion

1. A complete 3-tier architecture should be: the presentation layer, business layer, and data layer can run on three independent hosts (see figure 1 ). A complete N-tier architecture should be: client persistence layer, business layer, and data layer can run on at least three independent hosts (see figure 2 ). A layer can and can only directly access the public components of the layer at its direct lower layer. This can minimize dependencies between layers. In addition, it can achieve the best security of tier. An N-tier architecture provides the best scalability, security, and fault tolerance.
2. Tier generally represents a physical deployment host. Layer passing represents a logical component group of software on the functional area. Layer is a common and best way to implement the n-tier architecture. The tier and layer can be equal or not equal. A layer can run on an independent tier or multiple tier. Multiple layers can run on only one tier.
3. If a layer runs on an independent process, it can run on an independent host (Tier. However, this is not necessarily true. If the process communicates with another process in non-distributed IPC mode, the process runs on an independent host (Tier.
4. the N-tier architecture has the following advantages: good scalability, better and finer security control, good fault tolerance, independent tier upgrade and update, without affecting other tier capabilities, enabling friendly and effective development and maintenance, adding new features and improving reusability.
5. If a non-Embedded Database (such as ms SQL Server and Oracle) is used as the data layer, the database can always run on an independent host (Tier. In the instance shown in figure 1, a standard 2-tier architecture system shows that the layer and application layer can only run on the same host; standard 3-tier architecture system or N-tier architecture system display layer and application layer can run on a host respectively.
6. Too many tier will bring too much system complexity, development and maintenance time and cost. Therefore, the number of tier should be the minimum number of Tier that can be used to solve problems such as scalability, security, and failover. From the performance perspective, the number of tier should be determined based on the actual problem. Do not overdeploy redundant tier. In addition, a certain number of processes should be maintained on a deployed host to meet performance requirements. A good architecture design can easily meet these needs.
7. Distributed IPC communication (such as socket) allows a layer process to be deployed on a tier. In. net, WCF is a good method for implementing the n-tier architecture.
8. There are the following facts and rules for business data validation in the n-tier architecture:
A. any layer can implement business data verification. Generally, the closer the layer to the Client layer, the higher the application performance; the more business data is verified on the layer far from the client layer, the higher the reliability and robustness of the application. When verification is performed on the business layer or persistent layer, data access in any form is verified.
B. We need to consider how to balance performance, security, reliability, and system robustness to determine which layer to implement business data verification. At the same time, we also need to consider the actual situation of the project.
C. Verification is effective on the client. For example, JavaScript is used for verification on the web page, but some Web hackers are the same. The user intentionally or maliciously bypasses the client's data verification. Therefore, both the client and the server must be verified, while the service must also consider the resulting performance and reliability issues.
D. A better practice is to implement simple data verification on the client side from the performance perspective, while the complete data verification on the server side from the reliability perspective. Simple data verification refers to simple attribute value verification for instance entities. Complete data verification includes simple data verification and some complex verification, such as checking between multiple attribute values of an entity instance or between multiple similar or different types of entity instances.
E. For some Interactive Client applications, whether or not to implement data verification on the server side, we need to implement data verification on the client side to meet the Interactive Performance of the application. Game applications belong to this category.
F. The verification logic of a version should be implemented and maintained in one place. All layers share the verification logic of this version. This makes it easier to reuse, develop, maintain, and deploy, and also makes the verification logic run through the entire application.
9. Assuming that the development team can have control over all layers, there are some practical extension skills when developing N-tier architecture applications:
A. Try to adopt low coupling technologies, such as soap xml or interfaces, to decouple tier. In the OO development mode, a tier can only rely on its underlying tier interface, rather than its implementation. The purpose of this operation is to achieve maximum decoupling between tier. Decoupling brings benefits in development, unit testing, maintenance, upgrade, internal component modification capability, reusability, and other aspects.
B. Use automatic generation and maintenance tools whenever possible to manage a version of the POCO business entity class applied to the entire application system. This reduces errors caused by version conflicts, version ing, and manual encoding.
C. Use some automatic tools to map the data between the business entity class and the traditional database (data layer. For example, Entity Framework, nhib.pdf in. net, and hibernate in Java.
D. For more information, use code generators to manage a large number of other code similar to the style. If there is no code generator suitable for your use, develop one by yourself. C #, Java, XSLT, and other technologies make it easy for you to develop a code generator.
E. the business layer and persistent layer are easily tightly coupled. By adding an adaptive layer between the two layers, we can reduce the coupling between the two layers through interfaces. For example, the persistent Adapter Between the WCF Service Layer and Entity Framework is an adaptive layer.
F. In the persistent layer of the client, the Code shared by all clients should be transferred to an independent library to maximize code reuse for all clients.
G. Adding a cache layer to each layer can improve the system performance.
H. to adapt to business needs and technical changes, the N-tier architecture is designed to configure the tier architecture through the key-Value Pair configuration file, in this way, you can simply replace different tier architectures by updating the key-value pairs in the configuration file.