A prominent characteristic of the layered architecture is the separation of concerns between the components (separation of concerns). Only one layer assembly processing logic of the present layer. For example, the presentation layer components will only handle presentation logic, business layer components only to deal with business logic. Thanks to the separate components, make it easier for us to construct a valid and powerful role model. So that the application becomes better development, testing, management and maintenance.
Key concepts
Note that each layer in Table 1-2 are closed. This layered architecture is a very important feature. This means you must request the transfer layer by layer. For example, the request is passed to the presentation layer is first passed to the business layer, and then transmitted to the persistence layer, and finally transferred to the data layer.
So why does not allow direct access to the data layer, layer it. And a reading is obtained if only the data, presentation layer directly access the data layer, layer by layer to obtain data than to the much faster through. This involves a concept: the isolation layer.
Layer a layer of insulation that is changing the architecture does not affect the other layers: These changes affect the scope limited to the current level. If the presentation layer can directly access the persistence, persistence layer if the SQL changes, and this has a certain impact on the business layer and the presentation layer. Application will only become tight coupling, interdependence between components. This architecture will be very difficult to maintain.
From another aspect, the layered insulation that are independent between the layers, each layer architecture very little mutual understanding. To illustrate this concept Niubi place, imagine a super reconstruction, from the presentation layer into JSF JSP. The link between the presentation layer and the service layer assumptions of consistent service layer will not be affected by the reconstruction, which is used by the presentation layer and interface architecture is fully independent.
However, a closed architecture level also has the inconvenience, and sometimes should open a certain level. If you want to include some common service component architecture called by the components of the business to add a shared service layer. In this example, create a service layer usually is a good idea, because Architecturally, it limits sharing service access business layer (also not allowed to access the presentation layer). If there is no isolation layer, there is no framework to limit the visibility of any common service access layer, it is difficult to rights management.
In this example, the new service is in a layer, presentation layer components can not directly access the service layer below the business layer. But now the business layer but also access to services through the persistence layer to layer, which is also unreasonable. This is an old problem in a layered architecture, the solution is to open some of the layers. As shown in Table 1-3 service layer of the now open. Request can bypass this layer, this layer directly access the underlying layer. Since it is an open service layer, business layer can bypass the service layer, direct access to data persistence layer. This is very reasonable.
The concept of open and closed layer to determine the relationship between architectural layers and flow request, and provides access restrictions between the information necessary to understand the architecture in various layers to designers and developers. If the casual open or closed layer in the architecture, the entire project may have been tightly coupled, mess. After it is difficult to test, maintain and deploy.
Examples
To demonstrate layered architecture is how it works, imagine a scene, such as Table 1-4, the user sends a request for access to customer information. Black arrows user data is obtained from the database request flow, red arrows show the direction of the return flow of the user data. In this example, the user information from the customer order data and an array (customer orders).
The user interface simply accept the request and display customer information. It does not matter how the data is obtained, or that they have got what data to use the data table. If the user interface received a request to search for customer information, it will forward the request to the user delegate (Customer Delegate) module. This module can be found in the service layer module corresponding to process the corresponding data (constraints). Business layer in the customer object aggregates all the information required for the service request (access customer information in this case). This module calls the customer dao persistence layer to obtain customer information, call order dao order to get information. These modules will execute SQL statements, then returns the corresponding data to the business layer. When the customer object receives the data, it will then transfer the data to the polymerization customer delegate, then passes the data to the customer screen displayed in front of the user.
从技术的角度来说，有很多的方式能够实现这些模块。比如说在Java平台中，customer screen 对应的是 (JSF) Java Server Faces ,用 bean 组件来实现 customer delegate。用本地的Spring bean或者远程的EJB3 bean 来实现业务层中的customer object。上例中的数据访问可以用简单的POJP’s(Plain Old Java Objects)，或者可以用MyBatis，还可以用JDBC或者Hibernate 查询。Microsoft平台上，customer screen能用 .NET 库的ASP模块来访问业务层中的C#模块，用ADO来实现用户和订单数据的访问模块。
注意事项
分层架构是一个很可靠的架构模式。它适合大多数的应用。如果你不确定在项目中使用什么架构，分层架构是再好不过的了。然后，从架构的角度上来说，选择这个模式还要考虑很多的东西。
第一个要注意的就是 污水池反模式(architecture sinkhole anti-pattern)。
在这个模式中，请求流只是简单的穿过层次，不留一点云彩，或者说只留下一阵青烟。比如说界面层响应了一个获得数据的请求。响应层把这个请求传递给了业务层，业务层也只是传递了这个请求到持久层，持久层对数据库做简单的SQL查询获得用户的数据。这个数据按照原理返回，不会有任何的二次处理，返回到界面上。
每个分层架构或多或少都可能遇到这种场景。关键在于这样的请求有多少。80-20原则可以帮助你确定架构是否处于反污水模式。大概有百分之二十的请求仅仅是做简单的穿越，百分之八十的请求会做一些业务逻辑操作。然而，如果这个比例反过来，大部分的请求都是仅仅穿过层，不做逻辑操作。那么开放一些架构层会比较好。不过由于缺少了层次隔离，项目会变得难以控制。
模式分析
下面的的表里分析了分层架构的各个方面。
整体灵活性
Rating: Low
Analysis: Overall flexibility is the ability to respond to environmental change. Despite the changes in the hierarchical mode can be isolated from them, I want to do some of this architecture is also changing and time-consuming. Heavy and tight coupling between components often hierarchical model is what causes reduction of flexibility.
Ease of Deployment
Rating: Low
Analysis: It depends on how big the project you publish this mode, the publisher may be more trouble, especially yes. Little change one component may affect the release of the entire program (or most of the program). The publication must be in accordance with plans to publish in the non-business hours or on weekends. therefore. Stratified mode causes the application release is not smooth, reduces flexibility in the release.
Testability
Rating: High
Analysis: Because the components are in their hierarchy, can simulate the other layer, or directly remove the layer, the hierarchical model is easy to test. You can simulate a single display assembly, testing business components isolated. You can also simulate a business layer to test the display function.
performance
Rating: Low
Analysis: Despite some layered architecture performance was really good, but the characteristics of this model cause it to bring high performance. Because of a service request to cross all layers of the architecture, doing a lot of unnecessary work.
Flexibility
Rating: Low
Analysis: Because of this tight coupling mode trends in development, the scale is relatively large, with a layered architecture building programs are more difficult to expand. You can think of each layer is divided into separate physical module or simply the entire program into multiple nodes to expand a layered architecture, but the overall relationship is too close, making it difficult to expand.
Ease of development
Rating: Easy
analysis: difficulty in the development of the above, layered architecture has been relatively high score. Because of this architecture is familiar to all of us, is not difficult to achieve. Most companies in the development projects are distinguished by technical layer, this model for most commercial project development is very appropriate. The link between the company's organizational structure and their software architecture dubbed "Conway's law". You can Google it and look up this interesting link.