关于分层

       前一段时间做收费系统，没有用设计模式和接口，只是简单的三层，UI、BLL、DAL，外加一个Entity和一个供UI调用的方法类和全局类。

       这一次和大家合作，基于“多考虑设计模式”的中心，来重新建模。

       先说说抽象工厂模式：

       不论是用于BLL与DAL层之间（更换DB，即DAL），还是UI和BLL层之间（更换BLL），抽象工厂模式都会使“更换”更为灵活，极大地降低各层之间的耦合度。

 

       抽象工厂的优点：

i “易于更换产品系列”：具体工厂类只需在初始化的时候实现一次，改变具体工厂非常容易，只需改变具体工厂即可使用不同的产品配置。

ii 它让具体的创建实例过程与客户端分离，客户端通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。（客户端只认识IUser，至于是用SQLServerUser还是AccessUser来实现就不知道了。）

 

       抽象工厂的缺点：

如果要增加一张表Project，改动：至少增加三个类，IProject、SqlserverProject、AccessProject，还需要更改IFactory、SqlserverFactory、AccessFactory。

 

       用简单工厂来改进抽象工厂，+反射+配置文件

using System.Reflection; using System.Configuration; class DataAccess { private static readonly string AssemblyName="抽象工厂模式"; private static readonly string db=ConfigurationManager.AppSettings["DB"]; //读取配置文件 //运用反射，创建实例 public static IUser CreateUser() { string className=AssemblyName="." + db + "User"; return (IUser)Assembly.Load(AssemblyName).CreateInstance(className); } public static IDepartment CreateDepartment() { string className=AssemblyName="." + db + "Department"; return (IDepartment)Assembly.Load(AssemblyName).CreateInstance(className); } }

 

       用上抽象工厂模式之后，程序就由原来的三层迅速扩充为“UI—BLLFactory—IBLL—BLL—DALFactory—IDAL—DAL”七层，当然这只是最基本的模型，可根据需要进行调整。

 

       另：抽象工厂模式&接口

       抽象工厂模式离不开接口。

       看到网上有人这样问“为什么要继承于接口再实现其方法?,直接在类中定义方法不好吗?”

       I think：如果省略接口，直接在类中定义方法，那还用抽象工厂模式还有什么作用？抽象工厂就是为了灵活更换，加上接口，那么程序只需要知道调用接口就行了，而不需要知道到底是谁实现了该接口。

 

 

       当然我们组长还提出了一些其他模式，如固定临时用户收费的策略模式，组合查询的装饰模式，生成临时用户的原型模式，记录当前登录管理人员信息和系统设置信息的单例模式。

宏宏辛苦了！