petshop4.0 具体解释之中的一个（系统架构设计）
一、PetShop的系统架构设计
在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据訪问层、业务逻辑层（又或成为领域层）、表示层，如图所看到的：
图一：三层的分层式结构
数据訪问层：有时候也称为是持久层，其功能主要是负责数据库的訪问。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。假设要添�ORM的元素，那么就会包含对象和数据表之间的mapping，以及对象实体的持久化。在PetShop的数据訪问层中，并没有使用ORM，从而导致了代码量的添加�，能够看作是整个设计实现中的一大败笔。
业务逻辑层：是整个系统的核心，它与这个系统的业务（领域）有关。以PetShop为例，业务逻辑层的相关设计，均和网上宠物店特有的逻辑相关，比如查询宠物，下订单，加入�宠物到购物车等等。假设涉及到数据库的訪问，则调用数据訪问层。
表示层：是系统的UI部分，负责使用者与整个系统的交互。在这一层中，理想的状态是不应包括系统的业务逻辑。表示层中的逻辑代码，仅与界面元素有关。在PetShop中，是利用ASP.Net来设计的，因此包括了很多Web控件和相关逻辑。
分层式结构到底其优势何在？Martin Fowler在《Patterns of Enterprise Application Architecture》一书中给出了答案：
1、开发者能够仅仅关注整个结构中的当中某一层；
2、能够非常easy的用新的实现来替换原有层次的实现；
3、能够减少层与层之间的依赖；
4、有利于标准化；
5、利于各层逻辑的复用。
概括来说，分层式设计能够达至例如以下目的：分散关注、松散耦合、逻辑复用、标准定义。
一个好的分层式结构，能够使得开发者的分工更加明白。一旦定义好各层次之间的接口，负责不同逻辑设计的开发者就能够分散关注，齐头并进。比如UI人员仅仅需考虑用户界面的体验与操作，领域的设计人员能够仅关注业务逻辑的设计，而数据库设计人员也不必为繁琐的用户交互而头疼了。每一个开发者的任务得到了确认，开发进度就能够迅速的提高。
松散耦合的优点是显而易见的。假设一个系统没有分层，那么各自的逻辑都紧紧纠缠在一起，彼此间相互依赖，谁都是不可替换的。一旦发生改变，则牵一发而动全身，对项目的影响极为严重。减少层与层间的依赖性，既能够良好地保证未来的可扩展，在复用性上也是优势明显。每一个功能模块一旦定义好统一的接口，就能够被各个模块所调用，而不用为同样的功能进行反复地开发。
进行好的分层式结构设计，标准也是不可缺少的。仅仅有在一定程度的标准化基础上，这个系统才是可扩展的，可替换的。而层与层之间的通信也必定保证了接口的标准化。
“金无足赤，人无完人”，分层式结构也不可避免具有一些缺陷：
1、减少了系统的性能。这是不言而喻的。假设不採用分层式结构，非常多业务能够直接造訪数据库，以此获取对应的数据，现在却必须通过中间层来完毕。
2、有时会导致级联的改动。这样的改动尤其体现在自上而下的方向。假设在表示层中须要添加�一个功能，为保证其设计符合分层式结构，可能须要在对应的业务逻辑层和数据訪问层中都添加�对应的代码。
前面提到，PetShop的表示层是用ASP.Net设计的，也就是说，它应是一个BS系统。在.Net中，标准的BS分层式结构例如以下图所看到的：
图二：.Net中标准的BS分层式结构
随着PetShop版本号的更新，其分层式结构也在不断的完好，比如PetShop2.0，就没有採用标准的三层式结构，如图三：
图三：PetShop 2.0的体系架构
从图中我们能够看到，并没有明显的数据訪问层设计。这种设计尽管提高了数据訪问的性能，但也同一时候导致了业务逻辑层与数据訪问的职责混乱。一旦要求支持的数据库发生变化，或者须要改动数据訪问的逻辑，因为没有清晰的分层，会导致项目作大的改动。而随着硬件系统性能的提高，以及充分利用缓存、异步处理等机制，分层式结构所带来的性能影响差点儿能够忽略不计。
PetShop3.0纠正了此前层次不明的问题，将数据訪问逻辑作为单独的一层独立出来：
图四：PetShop 3.0的体系架构
PetShop4.0基本上延续了3.0的结构，但在性能上作了一定的改进，引入了缓存和异步处理机制，同一时候又充分利用了ASP.Net 2.0的新功能MemberShip，因此PetShop4.0的系统架构图例如以下所看到的：
图五：PetShop 4.0的体系架构
比較3.0和4.0的系统架构图，其核心的内容并没有发生变化。在数据訪问层（DAL）中，仍然採用DAL Interface抽象出数据訪问逻辑，并以DAL Factory作为数据訪问层对象的工厂模块。对于DAL Interface而言，分别有支持MS-SQL的SQL Server DAL和支持Oracle的Oracle DAL具体实现。而Model模块则包括了数据实体对象。其具体的模块结构图例如以下所看到的：
图六：数据訪问层的模块结构图
能够看到，在数据訪问层中，全然採用了“面向接口编程”思想。抽象出来的IDAL模块，脱离了与详细数据库的依赖，从而使得整个数据訪问层利于数据库迁移。DALFactory模块专门管理DAL对象的创建，便于业务逻辑层訪问。SQLServerDAL和OracleDAL模块均实现IDAL模块的接口，当中包括的逻辑就是对数据库的Select，Insert，Update和Delete操作。由于数据库类型的不同，对数据库的操作也有所不同，代码也会因此有所差别。
此外，抽象出来的IDAL模块，除了解除了向下的依赖之外，对于其上的业务逻辑层，相同仅存在弱依赖关系，例如以下图所看到的：
图七：业务逻辑层的模块结构图
图七中BLL是业务逻辑层的核心模块，它包括了整个系统的核心业务。在业务逻辑层中，不能直接訪问数据库，而必须通过数据訪问层。注意图中对数据訪问业务的调用，是通过接口模块IDAL来完毕的。既然与详细的数据訪问逻辑无关，则层与层之间的关系就是松散耦合的。假设此时须要改动数据訪问层的详细实现，仅仅要不涉及到IDAL的接口定义，那么业务逻辑层就不会受到不论什么影响。毕竟，详细实现的SQLServerDAL和OracalDAL根本就与业务逻辑层没有半点关系。
由于在PetShop 4.0中引入了异步处理机制。插入订单的策略能够分为同步和异步，两者的插入策略明显不同，但对于调用者而言，插入订单的接口是全然一样的，所以PetShop 4.0中设计了IBLLStrategy模块。尽管在IBLLStrategy模块中，不过简单的IOrderStategy，但同一时候也给出了一个范例和信息，那就是在业务逻辑的处理中，假设存在业务操作的多样化，或者是今后可能的变化，均应利用抽象的原理。或者使用接口，或者使用抽象类，从而脱离对详细业务的依赖。不过在PetShop中，由于业务逻辑相对简单，这样的思想体现得不够明显。也正由于此，PetShop将核心的业务逻辑都放到了一个模块BLL中，并没有将详细的实现和抽象严格的依照模块分开。所以表示层和业务逻辑层之间的调用关系，其耦合度相对较高：
图八：表示层的模块结构图
在图五中，各个层次中还引入了辅助的模块，如数据訪问层的Messaging模块，是为异步插入订单的功能提供，採用了MSMQ（Microsoft Messaging Queue）技术。而表示层的CacheDependency则提供缓存功能。这些特殊的模块，我会在此后的文章中具体介绍。
