软件分层应该如何分层

软件分层应该如何分层？

一般信息系统中最常见的是如下所列的4层：表示层，业务逻辑层，持久层，应用层。

模式介绍：

表示层(也称为UI层)：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。

应用层(也称为服务层)：服务层的作用就是将表现层与业务逻辑层之间完成解耦。那么表现层中就不会出现任何的业务代码，当然这样带来的好处也是显而易见的，就是当我们修改业务层代码时，我们不需要修改表现层的代码，

当然如果服务层设计的不好，那么可能会造成反效果。

业务逻辑层(也称为领域层)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。无疑是系统架构中体现核心价值的部分。它的关注点

主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域逻辑有关

数据访问层(也称为持久化层)：主要是针对非原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据库的操作，而不是数据，具体为业务逻辑层或表示层提供数据服务。

案例分析---SSH的分层：

1、在表示层中，首先通过JSP页面展示信息

2、在服务交互层中实现交互，负责传送请求(Request)和接收响应(Response)，然后Struts根据配置文件(struts-config.xml)将ActionServlet接收到的Request委派给相应的Action处理，然后action进行对请求处理并转发给JSP页面。

3、在业务逻辑层中，管理服务组件的Spring IoC容器负责向Struts2提供具体的Action对象，提供业务模型(Model)组件和该组件的协作对象数据处理(DAO)组件完成业务逻辑，并提供事务处理、缓冲池等容器组件以提升系统性能和保证数据的完整性。

4、在数据访问层中，则依赖于Hibernate的对象化映射和数据库交互，处理DAO组件请求的数据，并返回处理结果，给业务逻辑层。

以***重大技术需求为例

如果需求征集页面接到了一个添加需求的请求，用户填完表单并提交，在web.xml配置了Struts2的拦截器，拦截表单提交请求，服务交互层根据Struts2的配置文件去服务交互层层的DemandAction,寻找保存的方法，该方法调用业务逻辑层

的方法demandService.Save(),业务逻辑层的这个方法又继续调用数据持久层的方法把数据保存到数据库，调用完毕之后返回save，服务交互层根据返回的结果save由服务交互层调用业务层的显示需求列表方法，业务层调用数据持久层数

数据库读取需求信息，回到表现层显示需求列表界面。Spring提供的IoC容器，我们可以将对象之间的依赖关系交由Spring进行控制管理服务组件的Spring IoC容器负责向Struts2提供具体的Action对象，提供业务模型(Model)组件和该组件的

协作对象数据处理(DAO)组件完成业务逻辑。

二）微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。

表现层（UI）：通俗讲就是展现给用户的界面，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。

业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。也将业务逻辑层称为领域层。

数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增、删、改、查。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。也称为是持久层。数据访问层中包含实体层（Model 实体层）

JavaWeb中典型的三层架构是：Jsp Struts/spring Hibernate的开发模式

简单工厂模式与三层架构：

三层在简单工厂的思想和基础上，为了达到更好的可复用性，可扩展性，可维护性和灵活性，把简单工厂的逻辑层进一步的分解，把逻辑层分解为逻辑判断层和数据访问层，让她们彼此直接的耦合度达到最低。不管是简单工厂还是三层架构，它们

之间的最终目的是解耦，最终的效果是达到“高内聚，低耦合”的效果。三层架构我们并不陌生，它是来源于简单工厂，但是高于简单工厂，它把简单工厂的粒度更加细化了，但是它们最终的目的是达到解耦。

一个餐馆的例子，如果从买菜上菜到做菜都是一个人，那个人生病了这个餐馆就不能营业了。如果有三个人分别负责招待客人、买菜、做菜，他们三个人有一个人生病的话，另外两个做简单的调整是可以营业的。也就是一层发生修改不会影响另外两层的

工作。招待客人的相当于表示层，只负责招待客人，做菜的相当于业务逻辑层按照表示层给的参数做菜，买菜的相当于数据访问层，只负责按照厨师给的单子买菜。

三）展示层，业务层，持久层，和数据库层。

如表1-1，有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分层。与第一个四层不同的是，展示层负责处

理所有的界面展示以及交互逻辑，业务层负责处理请求对应的业务，持久层负责对数据的操作，数据层负责操作数据库。

案例分析：

（参考https://blog.csdn.net/bboyfeiyu/article/details/45136299#t1）

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

用户界面只管接受请求以及显示客户信息。它不管怎么得到数据的，或者说得到这些数据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会转发这个请求给用户委托(Customer Delegate)模块。这个模块能找到业务层里对应的模块处理

对应数据(约束关系)。业务层里的customer object聚合了业务请求需要的所有信息(在这个例子里获取客户信息)。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层。当 customer object收到数据以后，它就会聚合这些数据然后传递给 customer delegate,然后传递这些数据到customer screen 展示在用户面前。

三 分层模式的特点使用场景：

一般的桌面应用程序

电子商务Web应用程

模式特点：

每个模块必须属于某个层次，为上层提供服务；同时委派任务给下层模块。

任何一个模块，都不能逆层次调用；属于下层的模块，不得调用（耦合）上层或上层次的模块。任何一个模块，都不得跨层次调用。

设计模式实现：

　　门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。

　　策略模式——抽象层次会隐藏底层的实现细节，这就是策略模式最基本的设计，我们往往会把上层作为功能接口，下层作为可选的策略来实现。

优点

1、开发人员可以只关注整个结构中的其中某一层；

2、可以很容易的用新的实现来替换原有层次的实现；

3、可以降低层与层之间的依赖；

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明确

7、在后期维护的时候，极大地降低了维护成本和维护时间

缺点

1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。

2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码。

3、增加了开发成本。

一、  软件架构和分层设计

（一）  软件架构（software architecture）

      是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口(计算机科学术语)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。

（二）分层设计

      分层是表示将功能进行有序的分组：应用程序专用功能位于上层，跨越应用程序领域的功能位于中层，而配置环境专用功能位于低层。分层从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。子系统的分组标准包含以下几条规则可见度。各子系统只能与同一层及其下一层的子系统存在依赖关系。

（三）使用分层架构开发的必要性

    1、分层设计允许你分割功能进入不同区域。换句话说，层在设计中就是逻辑组件的分组。例如，A层可以访问B层，但B层不能访问A 层。

    2、用分层的方法，以提高应用程序的可维护性，并使其更容易扩展，以提高性能。

（四）设计分层的原则

    1、层意味着组建的逻辑分组。例如，对用户界面，业务逻辑和数据访问组建应该使用不同的不同的层。

    2、在一个层内组建应该聚合的。如业务层组建仅应提供与业务逻辑相关的操作，而不是提供其他操作。

    3、在设计的每一个层接口时要考虑好物理边界。如果通信扩展了物理边界，使用基于消息操作；否则使用基于对象操作。

    4、考虑使用接口类型（interface）来定义每层的接口。这将允许你创建该接口的不同实现，提高可测性。

    5、对于Web应用程序，在表示层和业务逻辑层之间实现基于消息的接口是一个好主意，即使这两层没有跨越物理边界。基于消息的接口更适合于无状态的Web操作。

二、软件的三层架构

（一）概述

      在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。

1、表示层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。 　　

2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。 　　

3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、查找等。

（二）三层结构原理： 　　

3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 　　

所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。

（三）各层的作用

数据访问层：

有时候也称为是持久层，其功能主要是负责数据库的访问，可以访问数据库系统、二进制文件、文本文档或是XML文档。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。主要是对原始数据（数据库或者文本文件等存放数据的形式）的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库,具体为业务逻辑层或表示层提供数据服务。

业务逻辑层：

主要是针对具体的问题的操作，也可以理解成对数据层的操作,对数据业务逻辑处理，如果说数据层是积木，那逻辑层就是对这些积木的搭建。业务逻辑层（Business Logic Layer）无疑是系统架构中体现核心价值的部分。它的关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计，也即是说它是与系统所应对的领域（Domain）逻辑有关，很多时候，也将业务逻辑层称为领域层。例如Martin Fowler在《Patternsof Enterprise Application Architecture》一书中，将整个架构分为三个主要的层：表示层、领域层和数据源层。作为领域驱动设计的先驱Eric Evans，对业务逻辑层作了更细致地划分，细分为应用层与领域层