软件架构模式-第一章分层架构(下)

原文地址  译者:克里斯托刘

模式实例

为更好描述分层架构怎样工作,考虑一个业务从业人员获取特定目标用户信息的需求,如图1-4所示。黑色箭头标志一路下到数据库的获取用户数据的请求流向,而红色箭头显示从下往上直到显示数据的屏幕这一数据反馈流向。在这个例子中,客户信息包含客户数据及订单数据(用户下的订单)。“用户屏幕”负责接收查询请求和显示用户信息,它并不知道数据在哪里、如何获取它、有多少数据库表格需要查询才能满足查询请求。一旦“用户屏幕”接收到查询客户信息的请求,它接着传递请求到“用户代理”模块。这个模块知道业务层中哪个模块可以处理该请求,同时知道如何调用该模块、传递哪些参数给该模块。业务层中的“用户类”负责收集所有业务请求需要的信息。该模块调用持续层的“用户数据访问接口”(Dao data access object)模块获取用户数据;调用“订单数据访问接口”模块获取订单信息。这些模块接着执行SQL语句去获得相关数据,再传递回业务层的“用户类”模块。一旦“用户类”获得数据,它会收集订单和用户信息两块数据同时传递回“用户代理”模块,“用户代理”模块继而传递数据回“用户屏幕”呈现给使用者。

从技术层面看,实际上有很多实现上述模块的方式。例如,在JAVA平台,用户屏幕可以是JSF和用户代理(作为bean部件管理者)的耦合。业务层的用户类可以是本地Spring或者远程EJB3的bean。数据访问部件可以做成简单的POJO,MyBatis XML Mapper 文件,或者原始JDBC调用或者Hibernate调用。从微软平台的视角,用户屏幕可以是使用.NET框架访问C#业务模块的ASP模块,同时用户和订单数据访问模块可以做成ADO(ActiveX Data Objects).

考虑

分层架构模式是一个稳定的通用模式,这使得它成为大部分应用程序的首选,特别是当你不确定使用哪个架构的时候。然而,当选择该模式时,从架构的角度,依然需要从很多方面进行考量。

首先需要注意的是污水池反模式architecture sinkhole anti-pattern,这种反模式描述了一种情况,当请求需要从多层间穿过,而穿过的层次(layer)只需要含有较少或者甚至不需要逻辑进行数据处理时。一个例子是,假设当表现层负责对用户获取业务数据需求这一操作做出反馈,表现层把需求传递给业务层,业务层继而直接传送给持久层,持久层继而调用简单的SQL查询命令获取用户数据。而后,数据一路一层层直接传回表现层,其他层次在此间,对数据没有额外的操作或者有复杂的逻辑计算。

每个层次结构都会至少有些污水池反模式的情况,关键在于,分析这种情况的百分比。通常“80-20规则”是一个示范是否处于污水池反模式的好例子。即,通常一个典型的组合是,20%的需求是简单的层间传递,80%的需求是传递层需要有相应的逻辑代码处理传输需求。然而,如果你发现比例是相反的,大部分需求是简单的层间传递,那么你需要开放一些层次,而这也使得层间分离不清楚,进而增加维护的难度系数。

另一个考量是,分层架构模式趋向于部署成一个集成的应用,即使你想把表现层和业务层分割到独立的部署单元。对于某些应用,这可能并不需要顾虑,但它会对部署、整体的鲁棒性、稳定性、性能、扩展性造成潜在的影响。

模式分析

下面表格包含分层结构模式的常用架构特征的评价和分析情况。这些评价是通过分析典型的模式范例,并衡量它趋向每个特征的能力和考量该模式所长而得出的。

整体的敏捷

评分:低

分析:整体的敏捷程度是能快速根据变化的环境反应的能力。虽然这种模式下,改变可以分散到不同的层次中,然而,由于该模式趋于一个集成的整体应用和其模块的紧密耦合性质,导致改变依然很艰难和耗时。

部署的方便

评分:低

分析:这取决于你如何实现这个架构,对于大型的应用,部署可能成为问题。一个小的改动需求,可能要求整个应用程序重新部署,计划,执行。从该模式特性出发,它不方便达成应用程序持续的交付流程,因此降低了该项的评分。

可测性

评分:高

分析:由于每个部件会属于特定的一个层次,其他的层次的作用可以被模仿或者消除,这使得该模式容易测试。比如,开发者可以模仿表现层的表现、反应,进而单独测试业务层,或者模仿业务层的动作,单独测试表现层。

性能

评分:低

分析:尽管一些层级架构可以表现出好的性能,然后从这个模式性质出发,它并不能有利于做出高性能程序,由于层间传递是缺乏效率。

可扩展性

评分:低

分析:由于该架构趋向高耦合度和集成程序的特质,应用程序通常难于扩展。你可以把各个层次分离到独立部署的应用中,或者复制整个应用到多个节点中,进而提高扩展性,但整体而言,覆盖的模块太广泛,这使得扩展的代价变得更昂贵。

开发容易性

评分:高

分析:该评分高的原因主要是该模式非常有名气以及实现过程不复杂。由于大部分公司开发应用正是按对应层次(表现、业务、数据)的功能来划分,这使得使用该模式成为一种自然的选择。公司的沟通和组织架构以及它开发软件的方式之间的联系,称为Conway’s law。具体你可以谷歌去搜索更多信息。

 

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 软件架构模式-第一章分层架构(下)

FavoriteLoading添加本文到我的收藏
  • Trackback are closed
  • Comments (0)
  1. No comments yet.

You must be logged in to post a comment.

return top