使用多层架构进行系统开发是现今系统设计的流行趋势。通过分解业务细节，将不同的功能代码分散开来，更利于系统的设计和开发，同时为可能的变更提供了更小的单元。

以下就是一个典型的多层体系结构图。



首先我们以“订单(Order)”为例，进行一个简单的业务分解。

1. 订单自然包括订单的内容(OrderInfo)，其中有诸如订单编号、商品名称、数量，以及金额等信息。
2. 有了订单信息，我们还需要一个存储订单的场所，那么自然需要有个操作读写的对象(OrderAccess)。
3. 为了外界能进行相关的订单操作，我们还需要有个业务逻辑对象(Order)，它提供创建新订单，向订单插入/删除商品，保存订单等操作。

通过上面的分析，我们基本上可以将一个业务逻辑完整地分割为：

业务实体 ---> OrderInfo
数据访问 ---> OrderAccess
业务逻辑 ---> Order

基于系统架构考虑，我们将这些对象分别放置在不同的逻辑单元中，这些逻辑单元就组成了“多层”。

业务实体层(Model) ---> 业务实体 ---> OrderInfo
数据访问层(DAL) ---> 数据访问 ---> OrderAccess
业务逻辑层(BLL) ---> 业务逻辑 ---> Order

同样以上面订单为例，我们进一步讲述各层对象的实现细节。

1. 客户基本上只依赖于 Order 和 OrderInfo，通过他们就可以操作业务的全部，它并不关心业务存储等细节。

2. 大多数时候我们会将 OrderAccess 设计成 Internal Protected 方式，OrderAccess 可以是一个抽象类或者接口。我更习惯于将其实现为抽象类，因为某些方法是调用其他方法来实现的，抽象类的设计可以减少实现类的代码数量。另外将该抽象类设计成工厂方法模式，通过 IoC 或者 "配置反射" 来获得具体的实现类，可以减少层之间的耦合，也便于数据系统的替换。

3. Order 多数时候可以实现为 Singleton 或者静态类，它只是提供了一系列的方法来操作某些逻辑，通过接受 OrderInfo 参数来获取信息。其本身无需保存任何状态。如果需要实现购物车，只需将 OrderInfo 存储到 Session 之中即可。

通过上面的例子，我们还可以发现多层的另外一个好处就是更利于团队协作开发。架构设计人员无需考虑具体的数据库实现代码，而将设计重点放在业务层面；数据库开发人员自然也可将重心放在数据库访问优化上。团队成员之间不再是一人负责一个业务模块，不再有了 n 个数据访问类，不再有 n 种不同的对象模式等等。从传统的 "瓦罐作坊" 演变为 "工业流水线"，更利于根据技术能力和业务熟悉度的差别来划分不同的角色。