关于工厂模式一问
工厂模式相信大家用的比较多吧，比如在三层中，如果数据库以后有可能用到别的，就会用工厂模式来做
我的问题是数据库改变了，数据层代码是必改无疑，既然都要改，那么工厂模式有什么用啊
有人说只要改配置文件就行了，难道你的数据层代码就不用改了吗，配置文件改了只是去调用例外一个数据层类
那我还不如直接在原来的类里面改啊

------解决方案--------------------
谁说工厂模式没用？ 能说点理由出来吗?
 它可以将代码模块化
假如你需要一件七匹狼衣服 你只需要呼叫
 七匹狼返回一件给你就是 可能你需要考虑 它们内部是怎样实现的 但不应该是你需要一件七匹狼衣服时考虑的事情

------解决方案--------------------
通过配置文件来设置不同的数据访问层的DLL文件！！！
------解决方案--------------------
然后实例化不同的对象
------解决方案--------------------
在工厂模式中用反射调用
------解决方案--------------------
可不改，数据库类操作对象都由逻辑层实例化。
------解决方案--------------------
一开始数据访问层DLL只有一个，你又加了一种访问方式，改改好了，取了个名字，这样就两个了，下次还可能三个四个。

这样系统给别人用的时候，业务逻辑层都要根据他们用的数据库改new语句了。这时工厂才开始派用场，你业务逻辑层不要new语句直接new数据层的类，用工厂给的类，工厂可以通过反射等方式读取配置文件生成数据层的类。

换句话说，工厂模式并不减少你的工作，反而增加你的工作，得到的好处是你的系统可以给不同需求的人用，而你不用改代码，只要改配置文件就可以了。
------解决方案--------------------

引用楼主 liubiaocai 的帖子:

工厂模式相信大家用的比较多吧，比如在三层中，如果数据库以后有可能用到别的，就会用工厂模式来做

------解决方案--------------------
噢，我没有说明为什么我说“工厂模式相信大家用的比较多吧，比如在三层中，如果数据库以后有可能用到别的，就会用工厂模式来做 ”这是错误的。

实际上，抽象编程核心是抽象。当你将几乎全部代码都改为抽象的高层次的代码，这时候你只是剩下了new一个具体对象的代码才是接触最终的具体类型，此时你使用“将new对象实例的代码推迟到一个方法中解决”是自然而然随心所欲地作出的，甚至根本意识不到需要为自己的着一个雷人的“xxx工厂”的名字。当你根本没有抽象的时候，奢谈“工厂”就会把精力放到许多诡异的设计上。
------解决方案--------------------
ado.net其实已经引入common命名空间，给我们设计好了工厂DbProviderFactories。楼主想的数据库问题都已经微软解决好了
------解决方案--------------------
高层模块不依赖于低层模块,两者都应依赖于抽象
------解决方案--------------------
类似的，同样是面向对象设计的最基础概念“委派”——.net中是delegate和event的设计概念，在模式中也被搞得七零八落、很诡异地散布于多个模式中，但是就是没有写明其实质。

面向对象对象设计是针对应用领域的、抽象的设计。当你学习OOAD的时候，对象类型的分析、各种动态模型的分析才是重点，甚至结合系统的api(cpu调度、存储、图形、io、通讯等等系统)，ORM或者OODBMS，以及不同的OO语言（甚至非OO编程语言）对于同样的设计的实现方法的差异，这些才是重点。基本概念上打转转就无法真正进行设计。
------解决方案--------------------
比方，你们公司开发的软件支持 Oracle ,mssql,mysql 
这样你们在销售部署的时候就很灵活了，随时可以将就客户现有的数据库。

像你说的那样，还得重现编译
------解决方案--------------------
学习
------解决方案--------------------

探讨

类似的，同样是面向对象设计的最基础概念“委派”——.net中是delegate和event的设计概念，在模式中也被搞得七零八落、很诡异地散布于多个模式中，但是就是没有写明其实质。

面向对象对象设计是针对应用领域的、抽象的设计。当你学习OOAD的时候，对象类型的分析、各种动态模型的分析才是重点，甚至结合系统的api(cpu调度、存储、图形、io、通讯等等系统)，ORM或者OODBMS，以及不同的OO语言（甚至非OO编程语言）对于同样的设计…