有必要使用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的类

如果你的Dao工厂使用很频繁，你可以使用对象池来处理啊，或者单态也可以阿

用spring的ioc都解决于，不用自已想什么DaoFactory

呵呵，很好的办法，定义接口，代码中针对接口编程，然后用spring将真正的实现注入。

如果实现修改了，只要简单的修改spring的配置文件就搞定。

是啊

SPRING的IOC的优势就在这里体现了!!

反向控制,或者叫做依赖注入!

恩啊，spring IOC很好很强大

这8算月经帖?

Spring的IOC并不能说解决了不用自己想DaoFactory。设计模式的什么时候都是有用的。

这里我认为还是有必要用抽象工厂的，因为我可以是注入工厂，这样可以更好。
注入不同的工厂就会产生不同的dao对象了。

我感觉用还是用工厂+OBJECTCACHE的方式比较好，如果不用SPRING的话。

有多少机会需要不停的更换数据库，如果不更换数据库，这个接口还有存在的必要吗！