2008-02-17
有必要使用dao时候使用工厂模式和接口吗？
先说明下是怎么使用dao的接口和工厂模式的（甚至包含抽象工厂模式）
1.当我们建立一个系统的时候，我们并不知道将要要用到什么样子的数据库，而且有可能随着
变化我们用到的数据库也有可能就被别的好的数据库代替。这个是使用dao接口及抽象工厂模式的前提
2.比如我们有一个user对象，我么对其操作要建立uerdao，我们仅仅知道对其操作，但是具体的做要要在数据库里面实现，不同的数据库操作不要一样，因此我们分成多种dao。但是这些别的人员并不一定要知道，别人用的是dao，没有必要去知道我用什么数据库来操作。因此uerDAo是个接口
诞生了userMySQLDAO，userOracleDAO等等。有了这些以后，使用者仅仅用个到userDAo的方法就可以
但是新的问题又出现了
3.userdao是一个接口我怎么去使用，我不能new我怎么使用
于是就出来了factory工厂可以魏你建立一个你自己想要的DAO就可以了。factory.getUserMySQLDAO。如果factory是一个一般的类，那么我们必须知道是什么样子的工厂，是mysql的工厂还是oracle的 工厂。
因此要使用抽象工厂模式
辩论：
这样好吗？
这样的factory每次都在用new来创建对象。会不会造成资源的浪费那？
为什么我们不能用一个静态的办法来代替那？
比如我仅仅定义一个userdao的类
1.当我们建立一个系统的时候，我们并不知道将要要用到什么样子的数据库，而且有可能随着
变化我们用到的数据库也有可能就被别的好的数据库代替。这个是使用dao接口及抽象工厂模式的前提
2.比如我们有一个user对象，我么对其操作要建立uerdao，我们仅仅知道对其操作，但是具体的做要要在数据库里面实现，不同的数据库操作不要一样，因此我们分成多种dao。但是这些别的人员并不一定要知道，别人用的是dao，没有必要去知道我用什么数据库来操作。因此uerDAo是个接口
诞生了userMySQLDAO，userOracleDAO等等。有了这些以后，使用者仅仅用个到userDAo的方法就可以
但是新的问题又出现了
3.userdao是一个接口我怎么去使用，我不能new我怎么使用
于是就出来了factory工厂可以魏你建立一个你自己想要的DAO就可以了。factory.getUserMySQLDAO。如果factory是一个一般的类，那么我们必须知道是什么样子的工厂，是mysql的工厂还是oracle的 工厂。
因此要使用抽象工厂模式
辩论：
这样好吗？
这样的factory每次都在用new来创建对象。会不会造成资源的浪费那？
为什么我们不能用一个静态的办法来代替那？
比如我仅仅定义一个userdao的类
- by harrison2010
- 浏览 (204)
- 评论 (15)
- 相关推荐
评论
这种抽象工厂的做法只是作为一种技术存在在spring这种框架中。
性能这方面，没有具体研究不好说。
这里我认为还是有必要用抽象工厂的，因为我可以是注入工厂，这样可以更好。
注入不同的工厂就会产生不同的dao对象了。
到底是使用静态工厂还是抽象工厂好呢?“注入不同的工厂就会产生不同的dao对象了”意思是说每个工厂负责产生一种dao，那么为什么不用一个工厂类得各个方法来产生不同dao呢？
我觉得有存在的必要,不说系统架构那么高级别的东西,
单是说单元测试就有必要,直接用具体类不能mock,也就不能unit test.
可以的，至少easymock最新版本已经可以了
另外dao单元测试意义不大，最好直接做集成测试，敏捷版讨论过
我觉得有存在的必要,不说系统架构那么高级别的东西,
单是说单元测试就有必要,直接用具体类不能mock,也就不能unit test.
这里我认为还是有必要用抽象工厂的，因为我可以是注入工厂，这样可以更好。
注入不同的工厂就会产生不同的dao对象了。
呵呵，很好的办法，定义接口，代码中针对接口编程，然后用spring将真正的实现注入。
如果实现修改了，只要简单的修改spring的配置文件就搞定。
恩啊，spring IOC很好很强大
用配置文件处理类之间的依赖关系，大部分人觉得很妙，我觉得虽然很妙，但是很烦。
如果数据库永远不会改变，就不要使用什么接口了，没必要，你的程序活不了那么久。
真的需要才使用，务实点。
另外，new几个dao没有关系，耗不了多少内存。一般情况无须对象池。
楼上几为大佬多心了，呵呵。
使用DAO的接口，这样内部对象系统就依赖于抽象，而非实现，正如楼主所说，这使得我们可以很容易的替换成不同的数据库而不用对中间层做过多的修改（单从对象系统而言，题外话：事实上数据库最不可能被换）。
当然，最后我们都得面对"现实”，要让系统跑起来，必须提供实现类来做“实事”。而工厂方法和抽象工厂，则是在快要new 对象出来的“最后一公里”的地方，为保持“抽象”作的最后努力：）
抽象的工厂生产抽象的产品，这一部分被归到系统框架中去。我们提供的具体的工厂，生产具体的产品，这一部分就是根据当前实际做的符合事实的事情。一般而已，产品是有状态的，产品对象之间不能互相替换。 如果碰巧产品是无状态的(比如通常的DaoImpl)，这样每次都创建新产品就比较浪费了。这个时候问题的焦点就转移来，这样我们可以用另外一个设计模式来解决这中无状态对象的创建与使用问题了，根据实际情况的不同，可以是singleton，可以是对象池，也可以直接每次需要的时候new一个新的。
Singleton是用来保证系统中有，而且只有一个对象实例，通常这个对象是有状态的，而且状态还很重要，不能通过再创建一个新对象来替代的;或者是创建一个开销特大。
对象池，则是提供了一些无状态（对于我们系统而言）的对象，需要的时候供取用，省去对象管理的麻烦和开销（题外话：一般来说，对象池里面的对象，对于内部而已也许是无状态无差别的，但是它很可能对应着非常重要、或者非常大开销的外部资源，比如各种网络链接等。池中对象对于它所处理的外部环境，很可能是有状态的）。
一般来说，我们所用的DaoImpl是“可以”只有一个的，如果每次都用新的，除了创建的开销外，也没别的害处。所以，如果除了介意创建时的开销，没有其他的考虑，用sinlgeton，用一个全局变量(静态类变量），或者一个对象池，都是行得通的。不过从简单的原则考虑，当然是越简单越好了。
我们遵守设计原则或者使用设计模式，是为了得到它的好处，同时也得注意代价。合算就用，得不偿失就不用。尤其要注意的是，从软件开发的商业角度来说，一个设计良好的对象系统并不是最高目标。
SPRING的IOC的优势就在这里体现了!!
反向控制,或者叫做依赖注入!
呵呵，很好的办法，定义接口，代码中针对接口编程，然后用spring将真正的实现注入。
如果实现修改了，只要简单的修改spring的配置文件就搞定。