一：业务层架构模式概述
在三层架构中，业务层负责所有业务相关的工作，包括根据输入数据或已有数据进行计算，对从表示层输入的数据进行验证，以及根据从表示层接收的命令来确定应该调用哪些数据访问逻辑。对于应用系统来说，业务层主要维护业务逻辑，是系统的核心部分。因此，在应用系统开发时，业务层的开发是最为关键的。
业务层的架构模式有多种，最著名的就是以下两种 ：
事务脚本模型（面向过程的设计）
领域模型（面向对象的设计）
二：事务脚本模型
事务脚本（Transaction Script）架构模型是按照传统的过程化方式组织业务逻辑，它将业务层的业务逻辑组织为一系列的事务脚本，每个事务脚本是一个访问数据库并执行计算的方法，每个事务脚本处理来自于表示层的单个请求。事务脚本通常被分组在一起，形成一个事务脚本类，以实现一到多个用例的业务逻辑。
在使用事务脚本模式组织业务逻辑时，业务层结构由如下三个部分组成：
事务脚本：事务脚本类由一些方法组成，一个方法对应一个事务脚本，也就是对应一个用户请求。
DTO：事务脚本类操作DTO（Data Transfer Object，数据传输对象）。DTO只有成员变量，没有方法。它包含来自数据库的数据，并由事务脚本返回给表示层。//实体类
为了更清晰地理解事务脚本架构模式，我们以开发一个简单的员工管理系统为示例，今天的作业就是这个了！再增加一个根据条件查询信息的
开发基于事务脚本模式的业务逻辑的过程由四个步骤组成：
1）识别事务脚本； 识别事务脚本可以通过分析用例或者分析用户界面原型，其中分析用户界面原型最为直接简单。
2）实现事务脚本； 现在我们已经识别了事务脚本，并确定了它们的参数和返回值类型。那么，整个过程的下一步就是实现事务脚本接口。
3）实现DTO； DTO在事务脚本和DAO之间，以及事务脚本和表示层之间传递。DAO使用DTO来返回需要从数据库获取的数据给事务脚本，事务脚本使用DTO传递数据到DAO，以更新数据库。事务脚本也会将DTO返回给表示层。
DTO只保存数据，只有成员变量和setter/getter方法。DTO及其成员变量可以组合如下三种识别技术来判断：
为每个数据库实体表定义一个DTO，DTO的成员变量与表的列对应。
为每个用户界面定义个DTO，DTO的成员变量包含显示在屏幕上的数据。
运用简单的OO分析和设计技术，识别类及其成员变量。
4）实现DAO。 每个DAO由一个接口和一个实现类组成。在上章我们已经学习过DAO的实现方法。这里不在详细讲述，只列出简单员工管理系统的DAO接口及实现类代码
事务脚本最大的优势在于使用简单。因为采用过程化设计，一个用户请求对应一个事务脚本，使用者无须拥有OO设计技能，不用识别类以及为类分配职责，任何初学者都可以很快掌握事务脚本模式来组织业务逻辑的方法。
缺点：因为事务脚本采用的是过程化设计的方法，所有业务逻辑都集中在事务脚本里面。很显然，将业务逻辑都集中在事务脚本里，违反了面向对象设计中单一职责等设计原则。这使得代码难以维护和理解，尤其是业务逻辑复杂的时候。
事务脚本模式虽然有缺点，但是至今仍然有很多开发团队采用该模式来组织业务层的业务逻辑。当业务逻辑相对比较简单时，采用事务脚本模式可以大大加快开发进度。同时，如果开发团队缺乏面向对象设计技能，采用事务脚本模式也是理智的选择。