导读：一路艰辛，我也走到了重构。在重构之前，师傅让用经典三层（UI、BLL、DAL）敲了登录、用户的增删改查，共五条线。从开始对三层的朦胧，到五条线结束，终于对三层有了逻辑上清晰的理解。然后就画了几天的类图，最后终于踏上了重构的道路。重构的第一步就是实现登录，考虑到换数据库的问题，就结合了设计模式上的抽象工厂模式。接下来，就说说在这个过程中的一些问题。

文章说明：本文不会贴登录实现的具体代码，纯属个人结合登录这条线的实现对于抽象工厂模式的理解，以及实现过程中出现的问题。

一、基础概念

抽象工厂模式（Abstract Factory)：提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。

好处1：易于交换产品系列，由于具体工厂类，例如IFactory factory=new AccessFactory()，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。

好处2：它让具体的创建实例过程与客户端分离，客户端是通过他们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

二、具体使用

1，为什么用？

就以我第一次做的经典三层和第二次用抽象工厂模式对比来说，第一次直接在D层写了用户名和用户密码的查询，如果需要更换数据库，那么，就得修改具体的SQL代码，一条两条很好改，那么很多很多条呢？所以，怎样快速准确的改变数据库访问是一个急需解决的问题。

2，使用过程

A：开始，使用经典三层写的代码，然后去具体的修改数据库访问代码；B：加入了新的代码实现。比如说我在登录方法中，写了两个方法，然后我再具体的去调用。C：也就是设计模式上的使用字符串变量，也就是传说中的给DB赋值。D：采用配置文件+反射实现数据库访问。

我在理解抽象工厂模式的过程中，经历了A—B—C—D这几个过程。一开始我什么都不知道，就知道要那样去写，但不明白为什么或者说哪里还可以再改进。一步一步的，我终于对抽象工厂模式有了更深的理解。

3，注意的地方

当将具体的值在这个地方配置好之后，工厂就会去自动的读取数据库，在这里是读取SQLServer，如果是Access，那么只需要将Value值改为相应的即可。

重新添加Access的具体访问，就变成了扩展而不是修改！

4，常见报错

在这个过程中，最常见的就是配置文件中找不到具体路径的问题和接口方法没有实现。

解决方案：1，首先，检查配置文件；然后，检查当前程序集是否正确（在设计模式中，只有一个层，所以在反射中所说的当前程序集和当前命名空间不是很明确，那么在重构中，这个当前，指的是D层。）；最后，改变生成路径。将D层的生成输出路径改到U层（原因不清楚，但问题确实解决了）。

2，首先，检查接口定义的方法是不是都已在D层实现；其次，检查接口中定义的方法和具体实现方法的返回类型是否一样。

三、我获得的便利

书上说的，很标准，但我还是不理解抽象工厂的具体好处。那么，我就说一下在使用过程中，我的具体获得的好处。

秉着单一职责原则，我将所有对User表的访问定义了一个访问接口，然后在D层中具体实现。开始没有使用这个模式，我就得具体的去实例化具体的类，用了这个模式后，我只需要定义一个工厂和接口，然后我需要使用的方法，都可以直接在后面被“.”出来。也不知道别人怎么看，反正在我看来，能让我 “.”出来东西，真的省了我很多事。至少我调用方法的时候，不用点开D层去看到底有哪些方法了。

四、个人感受

在这个过程中，我最大的感受是：不要用别人的成功压榨自己本就急躁的心，停下来，静下来，一步一步的去做，慢慢的，就会收获很多。

一开始学完三层，看个视频，做个登录，就吵吵着要重构，结果是弄的一团糟，师傅一问，啥啥不知道。谢谢师傅为我定下的循序渐进的学习方案，让我一步一步的理解。不像之前那样，就知道看了师哥师姐的博客要那么去做，但为什么要去做，怎样去做，哪里可以改进，是什么都不知道，就知道照抄代码。

在学习的过程中，有时候，我们知道所以然就够了，但有些时候，我们还必须知道之所以然，举一反三。至于这有时候和有些时候具体指什么时候，全靠大家各自斟酌。

请大家多多指点，谢谢！