下面以用户实体为例，业务逻辑层接口设计如表所示。 需求 获取用户信息 获取全部用户 获取特定状态用户 添加新用户 删除用户 更新用户信息 修改用户密码 修改用户状态 判断是否存在此用户 接口 GetModel GetModelList GetModelList AddUser DeleteUser UpdateUser UpdatePwd 参数 用户名 无 用户状态 返回值 用户实体类 用户实体类 用户实体类 操作类型 单实体查询 集合实体查询 集合实体查询 创建 删除 更新 更新 更新 函数查询 用户实体类 表示是否成功的布尔值 表示是否成功用户ID 的布尔值 用户实体类 表示是否成功的布尔值 用户实体类 表示是否成功的布尔值 UpdateUserState 用户状态ID、表示是否成功的布尔值 用户ID IsExist 用户名
表示是否成功的布尔值 具体UsersBLL的实现代码请参考附录一。
四、三层架构中常用的设计模式
4.1 依赖注入与控制反转
依赖注入（Dependency Injection）和控制反转（Inversion of Control）是同一
个概念。具体含义是：当某个角色（调用者）需要另一个角色（被调用者）的协助时，在传统的程序设计过程中，通常由调用者来创建被调用者的实例。但在具有依赖注入的系统里，创建被调用者的工作不再由调用者来完成，因此称为控制反转。创建被调用者实例的工作通常由Ioc容器来完成，然后注入调用者，因此也称为依赖注入。
具体到分层架构中，依赖注入可以这样理解：当上层类的需要调用下层类功
能时，不再是由上层类直接实例化下层类，而是通过IoC容器获取一个下层类的
实例，然后注入到上层类中。
以用户实体的业务逻辑层调用数据访问层为例，在没有依赖注入机制的系统
中，用户的业务逻辑层类直接实例化数据访问层类，如图4.1(a)所示。在加入依赖注入机制后，实例化数据访问层的任务就交给了IoC容器，如图4.5(b)所示
图4.1（a）非IoC耦合示意
图4.1(b) IoC耦合示意
这样做的好处是什么呢？前面已经提到过，在我们设计的分层架构中层次之
间一定不能出现具体耦合。如果按照图4.1(a)的模式，业务逻辑层势必要实例化具体的数据访问层类，这就造成了紧耦合。而在依赖注入机制下，业务逻辑层可以只依赖数据访问层的接口，至于在运行时得到的是哪种数据访问层类，它并不需要知道，他只需从IoC中获得相应的类，然后调用它的方法完成任务就行了。
而IoC内部可以有一套配置机制，这样就可以根据不同的配置信息，动态决定实例化那一种数据访问层类，从而实现了两个层次间的解耦。由于团队的各方面的因素，本文的在线购物实例采用了图4.1(a)的模式。图4.1(b) 的模式并不展开讨论，想了解这方面知识的读者请查阅相关的资料。 4.2 Abstract Factory模式在三层架构的应用
Abstract Factory模式是在依赖注入机制中广泛采用的设计模式，Spring的IoC
容器就采用了这个经典模式。它的中文译名叫做“抽象工厂”，其定义是这样的：提供一个接口，用于创建相关或依赖对象的家族，而不需要指定具体类。
图4.2抽象工厂模式
图4.2是Abstract Factory模式的示意图。IFactory为工厂接口，它内部定义了生产一系列产品的方法。其它所有工厂都必须实现这个接口，但它们生产的产品系列是不一样的，而一系列产品的每一种产品都实现自同一个产品接口。这样，客户（Client）仅需要依赖工厂接口和产品接口。如果配置文件决定实例化哪一个工厂，则客户就能在运行时动态获得不同的产品系列，从而系统获得了依赖注入的功能。
下面具体到本课题中，讨论抽象工厂在依赖注入机制中的应用。以数据访问
层注入到业务逻辑层为例（业务逻辑层注入到表示层的原理类似），先假设系统
仅有用户一个实体，并且我们的系统需要能访问SQLServer和Access两个数据库，那么，系统中就需呀SqlServerDAL和AccessDAL两个数据访问层，它们都含有一个数据访问类，分别是SqlServerUsersDAL（对应本文实例工程BookStoreDAL中SqlServer文件夹下的Users）和AccessUsersDAL（对应本文实例工程BookStoreDAL中Access文件夹下的Users）。此时，用户的业务逻辑层类UsersBLL（对应本文实例工程BookStoreBLL中的Users）作为客户类，不应该与具体的数据访问层类耦合，而应该先定义接口IUsersDAL（对应本文实例工程BookStoreiDAL中的IUsers）接口，让业务逻辑层与这个接口耦合。再设计SqlServerDALFactory与AccessDALFactory，分别作为生成两种数据访问层的工厂，最后通过配置信息，决定在业务逻辑层中实例化哪个工厂。
图4.3 抽象工厂模式在三层架构中的应用
4.3 三层架构中的外观模式（Facade）
外观模式（Facade）为子系统中的一组接口提供一个一致的界面，此模式定
义了一个高层接口，这个接口使得这一子系统更加容易使用[1]
图4.4 外观模式（Facade）结构图
图4.2是Facade模式的示意图。在设计初期阶段，应该要有意识的讲不同的两个层分离。经典的三层架构，就需要考虑在数据访问层、业务逻辑层和表示层的层与层之间建立外观Facade，这样可以为复杂的子系统提供一个简单的接口，使得耦合大大降低。
致谢
感谢指导老师对我的关心、鼓励与帮助；感谢同学张三、李四和王五的热情支持和真诚帮助；感谢家人在十几年的求学生涯中，给予的教导、爱护与支持，促使我在人生的道路上不断奋力前行。
由于自身知识的不足，文中必存在不少疏漏和不足。敬请老师提出宝贵的意见，并衷心感谢。
[参考文献]
[1]Erich Gamm, Richard Helm, Ralph Johnson, JohnVlissides.设计模式：可复用面向对象软件的基础[M].北京:机械工业出版社，2007.
[2]Robert C.Martin.敏捷软件开发：原则、模式与实践[M].北京:清华大学出版社，2003. [3]阎宏.Java与模式[M].北京:电子工业出版社，2002.