分层模式-认识

适用环境：最通常的架构模式就是分层架构模式，即所谓的N层架构。这种模式对大部分JAVAEE应用程序来说是标准模式，因此被大部分架构师、软件设计师、开发者广泛知晓。由于分层架构模式和公司里传统的IT沟通以及组织结构非常类似，使得它成为大多数商务应用开发最自然的选择。

解决的问题：

 

在分层架构模式中，它将应用分成多个水平层，每个水平层在应用中担任一个专门的角色（比如表现层或者业务逻辑）。尽管分层架构模型并没有指定必须的层次个数以及类型，但大部分这种模型都由4个标准层次构成：表现层、业务层、持久层、数据库（图1）。在一些情况下，业务层和持久层可以合为一个单一的业务层中，特别是当持久层的逻辑（比如SQL或者HSQL）内嵌于业务层中。因此小应用程序通常只有三个层‑次，至于更大或者更多的复杂商业应用可能会包含5个或者更多的层次。在此架构中每层都有一个特定的角色和责任。比如，表现层负责处理所有用户交互和浏览器沟通的逻辑，业务层可能会负责执行和要求相关的特定业务。在分层架构中，每一层只需要围绕满足特定业务请求的工作形成抽象。比如表现层不需要了解或关心如何获取客户数据；它只需要按特定格式展示信息；同理，业务层也无需关心如何展示客户数据，甚至业务层都无需知道客户数据从哪里来；业务层只需要从持久层获取数据，运用这些数据执行业务逻辑，再把信息上传给表现层。

 

 

这种模型一个强大的特征是隔离开组件按照不同层次。每个层次中的组件只需要处理属于那个层次的功能逻辑即可。比如在展示层的组件只需要处理展示的逻辑，而业务层中的组件只需要处理业务逻辑。这样的组件分类方式便于建立高效的角色和责任制的模型，同时也会方便开发、测试、管理、维护应用，因为设计完善的组件接口以及限制的组件功能范围。

 

方案：

 

分层架构是常用的架构模式，对于一个大系统可以划分为几个子系统，各子系统位于不同的抽象层次。各层间上层依赖下层服务，下层不能依赖上层。
消息可以从上向下，也可以从下向上。自顶向下调用下层接口，称为请求。自低向上的通信，称为通知，一般使用回调方法，从而实现单路径耦合。
【分层的步骤】

 

1、定义抽象准则

 

2、根据准则定义抽象层数

 

3、给每个层命名并指定任务

 

4、指定服务

 

5、细化分层，重复上述步骤，直到一个稳定的分层结构

 

6、为每层指定接口

 

7、构建独立层

 

8、指定层间通信，分离临接层

 

9、设计错误处理策略

【分层的优点】

分层架构模式是个可靠的通用模式，对于大部分应用它是个很好的开始，尤其当不知道哪种结构适合使用时。

它有如下几点优势：重用性好、标准化支持、局部依赖、可替换性
【分层的缺点】

分层主要有以下的缺点：影响多层次的修改；降低了效率；多层传递，重复的工作；层的粒度难以把握。

分层的多层传递中有现象被称为污水池反模式（architecture sinkhole anti-pattern）。该反模式描述的是这样的场景，请求流穿过架构的很多层，每一层只有少量的甚至没有业务逻辑。例如，假设展示层响应用户的请求获取客户信息，展示层将请求传递给业务层，业务层什么也不做，仅仅将请求直接传递给持久层，持久层执行SQL语句获取数据。数据在回传过程中没有经过任何的处理。

每个分层架构都可能会有一些场景落入污水池反模式。然而关键是分析这样的请求占了多少比例。通常80-20定律可用来分析是否落入了污水池反模式。当反模式的比例比较大时，你或许考虑将某些层开放，这时要注意缺乏层隔离，会使得以后修改时比较困难。

分层架构会使应用变得庞大，即使把表示层和业务层分成了单独的部署单元。这对某些应用不需要考虑，但是也会带来一些部署的隐患，如健壮性、可靠性、性能和可伸缩性。

 

【常用分层】

三层模型：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。

四层模型：表示层，应用逻辑层，领域模型层，数据库层

 

实例：

为更好描述分层架构怎样工作，考虑一个业务从业人员获取特定目标用户信息的需求，如图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）.

 下面以emp数据表（empno、ename、job、hiredate、sal、comm，都是基本字段）为例分析一个操作，客户要求可以实现如下的几个功能：

                   · 【业务层】增加一个新雇员信息；

                            |-〖数据层〗要根据增加的雇员编号查看此雇员是否存在；

                            |-〖数据层〗如果雇员不存在则执行插入操作，如果存在则不插入；

                   · 【业务层】修改一个雇员的信息；

                            |-〖数据层〗直接传入新的数据即可，如果没有修改返回的更新行数是0；

                   · 【业务层】删除一个雇员的信息；

                            |-〖数据层〗直接传入要删除的雇员编号即可，如果没有此雇员信息返回的是0；

                   · 【业务层】根据编号查询一个雇员的信息；

                            |-〖数据层〗返回一个雇员的完整信息；

· 【业务层】取得全部雇员的信息，要求可以实现模糊查询和分页显示，查询结果除了返回数据之外，还要求知道模糊或全部查询时所返回的全部数据量：

                            |-〖数据层〗模糊或查询全部满足条件的雇员数据，多个数据；

                            |-〖数据层〗使用COUNT()进行满足条件的数据统计。

 

转载于:https://www.cnblogs.com/x-m-/p/9075216.html