Provider和工厂模式的区别？

Question

一般都是为了用来动态加载不同的数据库实现。
感觉差不多啊，那位给解惑下？

Answer 1

Provider模式如：MembershipProvider、SiteMapProvider等，
它的出现使我们的应用程序有了更大的扩展性，可以是一个数据工厂的提供者，也可以是一个逻辑处理的提供者。
而实现这种模式却是相当的简单，只需实现四步专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类或接口。简单工厂模式又称为静态工厂方法（Static Factory Method）模式，属于类的创建型模式，通常根据一个条件（参数）来返回不同的类的实例。
参考
http://www.cnblogs.com/liangwei389/archive/2008/11/29/1343810.html
http://www.cnblogs.com/bit-sand/archive/2008/01/25/simple_Factory_Pattern.html

Answer 2

其实，我觉得一个解决复杂一点的某个行业的功能的“骨架”叫做模式才好。如果把两三条简单代码的不同写法叫做模式，肯定会产生无数雷人的模式概念，你会在遇到一个只有几十行代码的行业应用框架时觉得它一下子“符合十种模式”而无所适从。然而现在的模式已经是如此了。如果你去看操作系统的磁盘调度结构和算法，或者一个会计账簿的结构和算法，或者MembershipProvider涉及的class和控制方法，等等，此时注重框架而轻视模式比较好。应该把精力放在对框架的研究上，传统意义上的“模式”严重脱离开具体应用设计了。例如我说“for循环语句”是专门用来指导你设计“所有”循环操作的程序的，你一定觉得这是废话。但是一个模式这样说你就不觉得是废话。可是，模式仍然只是一些简单的控制结构，而不是应用框架。因此有很多人说“学模式但是不要沉迷于模式”，其实也只是因为它根本就是基本的编程结构，就好像中国武术门派林立于是同样打出一拳有十几种叫法，每一个门派对于打出一拳都有细微的差别，甚至动作、速度完全一样而“心法”的解释稍有不同也叫做不同的模式。练拳不可不从形似练起，但是你不一定只学几百种动作来唬人，而更要学到感觉和反应（最终可能在你心里只剩下几招克敌制胜），才是学会了拳术。因此研究模式和研究解决实际问题的框架是不可同日而语的。我同意3楼的主要意思，只是需要对模式给以一定的地位，说明人人都会从纠缠于模式过渡到研究具体框架而受益。只能看到模式而看不到行业应用框架就好像一叶障目，是需要在软件工程方面走得更远一些的。