软件设计分层思想《xiǎng》的作用软件分层应该如何分层？

软件分层应该如何分层？一般信息系统中最常见的是如下所列的4层：表示层，业务逻辑层，持久层，应用层。模式介绍：表示层#28也称为UI层#29：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。应用层#28也称为服务层#29：服务层的作用就是将表现层与业务逻辑层之间完成解耦

软件分层应该如何分层？

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

模【练：mó】式介绍：

表示层#28也称为UI层#29：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
应用层#28也称为服务层#29：服务层的作用就是将表现层与业务逻辑层之间完成解耦。那么表现层中就不会出现任何的业务代码，当然这样带来的好处也是显而易见的，就是当我们修改业务层代码时，我们不需要修改表现层的代码，

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

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

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

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

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

1、在表示层中，首先通过JSP页面展示信《拼音：xìn》息

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

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

4、在数据访问层中，则{pinyin：zé}依赖于（繁体：於）Hibernate的对象化映{读：yìng}射和数据库交互，处理DAO组件请求的数据，并返回处理结果，给业务逻辑层。

以#2A#2A#2A重【拼音：zhòng】大技术需求为例

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

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

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

协澳门威尼斯人作对象数据处理#28DAO#29组件完成业务逻（繁：邏）辑。

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

表现层（UI）：通俗讲就是展现给用户的界面，用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。
业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。也将业务逻辑层称为领域层
数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增、删、改、查。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。也称为是持久层。数据访问层中包含实体层（Model 实体层）

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

简单工厂模(读：mó)式与三层架构：

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

之间的最终目的是解耦，最终的效果是达到“高内聚，低耦合”的效果。三层架构我们并不陌生，它是来源于（繁：於）简单工厂，但是高于简单工厂，它把简单dān 工厂的【拼音：de】粒度更加细化了，但是它们最终的目的是达到解耦。

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

工作。招待客人的相当于表示层，只负责招待客人，做菜的相当于业务逻辑层按照表示层给的参数[繁：數]做《zuò》菜，买菜的相当于数据《繁体：據》访问层，只负责按照厨师给的单子买菜。

三）展示层，业务层，持久层，和数据（繁：據）库层。

如表{练：biǎo}1-1，有时候，业务层和持久层会合并成单独的一个业务层，尤其是持久层的逻辑绑定在业务层的组件当中。因此，有一些小的应用可能只有3层，一些有着更复杂的业务的大应用可能有5层或者更多的分[读：fēn]层。与第一个四层不（练：bù）同的是，展示层负责处

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

案例分fēn 析：

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

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

用户界面只管接受请求以及显示客户信息。它{练：tā}不管怎么得到数据的，或者说得到这些数《繁体：數》据要用到哪些数据表。如果用户界面接到了一个查询客户信息的请求，它就会[繁：會]转发这个请求给用户委托#28Customer Delegate#29模块。这个模块能找到业务层里对应的模块处理

对应数(繁体：數)据#28约束关系《繁体：係》#29。业务层里的customer object聚合了业务（繁：務）请求需要的所有信息#28在这个例子里获取客户信息#29。这个模块调用持久层中的 customer dao 来得到客户信息，调用order dao来得到订单信息。这些模块会执行SQL语句，然后返回相应的数据给业务层

当 customer object收到数据以后，它就会聚合这些数据（繁体：據）然后传递给{繁体：給} customer delegate，然后传递这些数据到customer screen 展示在用(读：yòng)户面前。

三{练：sān} 分层模式的特点使用场景：