测试架构师：软件架构模式之分层架构 2

示例

为了演示分层架构是如何工做的，想象一个场景，如表1-4，用户发出了一个请求要得到客户的信息。黑色的箭头是从数据库中得到用户数据的请求流，红色箭头显示用户数据的返回流的方向。在这个例子中，用户信息由客户数据和订单数组组成(客户下的订单)。

用户界面只管接受请求以及显示客户信息。它无论怎么获得数据的，或者说获得这些数据要用到哪些数据表。若是用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理对应数据(约束关系)。业务层里的customer object聚合了业务请求须要的全部信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来获得客户信息，调用order dao来获得订单信息。这些模块会执行SQL语句，而后返回相应的数据给业务层。当 customer object收到数据之后，它就会聚合这些数据而后传递给 customer delegate,而后传递这些数据到customer screen 展现在用户面前。

从技术的角度来讲，有不少的方式可以实现这些模块。好比说在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原则能够帮助你肯定架构是否处于反污水模式。大概有百分之二十的请求仅仅是作简单的穿越，百分之八十的请求会作一些业务逻辑操做。然而，若是这个比例反过来，大部分的请求都是仅仅穿过层，不作逻辑操做。那么开放一些架构层会比较好。不过因为缺乏了层次隔离，项目会变得难以控制。

模式分析

下面的的表里分析了分层架构的各个方面。

总体灵活性

评级:低 
分析:整体灵活性是响应环境变化的能力。尽管分层模式中的变化能够隔绝起来，想在这种架构中作一些也改变也是而且费时费力的。分层模式的笨重以及常常出现的组件之间的紧耦合是致使灵活性下降的缘由。

易于部署

评级:低 
分析:这取决于你怎么发布这种模式，发布程序可能比较麻烦，尤为是很大的项目。一个组件的小小改动可能会影响到整个程序的发布(或者程序的大部分)。发布必须是按照计划，在非工做时间或者周末进行发布。所以。分层模式致使应用发布一点也不流畅，在发布上下降了灵活性。

可测试性

评级:高 
分析:由于组件都处于各自的层次中，能够模拟其余的层，或者说直接去掉层，因此分层模式很容易测试。开发者能够单独模拟一个展现组件，对业务组件进行隔绝测试。还能够模拟业务层来测试某个展现功能。

性能

评级:低 
分析:尽管某些分层架构的性能表现的确不错，可是这个模式的特色致使它没法带来高性能。由于一次业务请求要穿越全部的架构层，作了不少没必要要的工做。

伸缩性

评级:低 
分析:因为这种模式以紧密耦合的趋势在发展，规模也比较大，用分层架构构建的程序都比较难以扩展。你能够把各个层分红单独的物理模块或者干脆把整个程序分红多个节点来扩展分层架构，可是整体的关系过于紧密，这样很难扩展。

易开发性

评级:容易 分析:在开发难度上面，分层架构获得了比较高的分数。由于这种架构对你们来讲很熟悉，不难实现。大部分公司在开发项目的都是经过层来区分技术的，这种模式对于大多数的商业项目开发来讲都很合适。公司的组织架构和他们软件架构之间的联系被戏称为”Conway’s law”。你能够Google一下查查这个有趣的联系。