三层构架与反射工厂的笔记

以前做过很多个网站系统，大都是用asp或者php做的，.net也用过，不过是用asp的思路来做.net，基本体现不出vs面向对象的特征。
    最近也要做一个网站，决心用c#，用严格的三层构架+反射工厂来做。于是网上找了一些示例的代码，开始看的是Shangducms和他的开发文档，看完之后，什么感觉没有，一头雾水。连三层构架和反射工厂的含义都没领会。然后听说微软的petshop不错，于是下载petshop4.0，又在csdn找到某大侠写的《petshop详解》，今晚上读了--数据访问层的相关介绍，终于对其构架有了一定的认识。感谢...
   下面吧我认为的精髓部分写下：
    在PetShop中，系统需要处理的数据库对象分为两类：一是数据实体，对应数据库中相应的数据表。它们没有行为，仅用于表现对象的数据。这些实体类都被放到Model程序集中，例如数据表Order对应的实体类OrderInfo，我的理解就是按照数据表的结构创建一个对应的类。这些类的属性分别映射了数据表的列，而每一个对象实例也恰恰对应于数据表的每一行。第二类对象就是对数据表的操作（Select，Insert，Update和Delete）他们仅具有行为而与数据无关，因此它们均被抽象为一个单独的接口模块IDAL，例如数据表Order对应的接口IOrder，其他的都是IXXX，（IXXX）就是接口。
    将数据实体与相关的数据库操作分离出来，符合面向对象的精神。首先，它体现了“职责分离”的原则。将数据实体与其行为分开，使得两者之间依赖减弱，当数据行为发生改变时，并不影响Model模块中的数据实体对象，避免了因一个类职责过多、过大，从而导致该类的引用者发生“灾难性”的影响。其次，它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL，与具体的数据库访问实现完全隔离。这种与实现无关的设计，保证了系统的可扩展性，同时也保证了数据库的可移植性。
    现在我们已经有了数据实体，数据对象的抽象接口和实现，可以说有关数据库访问的主体就已经完成了。留待我们的还有两个问题需要解决：
    1、数据对象创建的管理
    2、利于数据库的移植
    在PetShop中，要创建的数据对象包括Order，Product，Category，Inventory，Item。在前面的设计中，这些对象已经被抽象为对应的接口，而其实现则根据数据库的不同而有所不同。也就是说，创建的对象有多种类别，而每种类别又有不同的实现，这是典型的抽象工厂模式的应用场景。
    例如，创建SQL Server的Order对象如下：PetShopFactory factory = new SQLServerFactory();IOrder = factory.CreateOrder();
    要考虑到数据库的可移植性，则factory必须作为一个全局变量，并在主程序运行时被实例化。但这样的设计虽然已经达到了“封装变化”的目的，但在创建PetShopFactory对象时，仍不可避免的出现了具体的类SQLServerFactory，也即是说，程序在这个层面上产生了与SQLServerFactory的强依赖。一旦整个系统要求支持Oracle，那么还需要修改这行代码为：PetShopFactory factory = new OracleFactory();
修改代码的这种行为显然是不可接受的。解决的办法是“依赖注入”。“依赖注入”的功能通常是用专门的IoC容器提供的，在Java平台下，这样的容器包括Spring，PicoContainer等。而在.Net平台下，最常见的则是Spring.Net。不过，在PetShop系统中，并不需要专门的容器来实现“依赖注入”，简单的做法还是利用配置文件和反射功能来实现。也就是说，我们可以在web.config文件中，配置好具体的Factory对象的完整的类名。然而，当我们利用配置文件和反射功能时，具体工厂的创建就显得有些“画蛇添足”了，我们完全可以在配置文件中，直接指向具体的数据库对象实现类，例如PetShop.SQLServerDAL.IOrder。那么，抽象工厂模式中的相关工厂就可以简化为一个工厂类了，所以我将这种模式称之为“具有简单工厂特质的抽象工厂模式”