有必要使用dao时候使用工厂模式和接口吗？

我觉得有存在的必要,不说系统架构那么高级别的东西,
单是说单元测试就有必要,直接用具体类不能mock,也就不能unit test.

可以的，至少easymock最新版本已经可以了
另外dao单元测试意义不大，最好直接做集成测试，敏捷版讨论过

到底是使用静态工厂还是抽象工厂好呢?“注入不同的工厂就会产生不同的dao对象了”意思是说每个工厂负责产生一种dao，那么为什么不用一个工厂类得各个方法来产生不同dao呢？

我觉得就算依赖注入也是注入的DaoFactory，没听过注入Dao的，IOC可以说是工厂模式精华体现，但是和传统工厂有本质区别。

工厂一般有两个作用：对对象得创建过程步骤进行统一管理；对对象的创建种类进行统一管理。
我有一次用第三方的邮件开发包连接该公司得邮件服务器，起先没有用工厂，没什么问题正常，可是到后来需要做灾难备份，一台邮件服务器宕机了，使用另外一台，我也没太在意，因为我觉得这个是邮件服务器自带得功能，当右键负责人说这个功能需服务器不提供要我手动完成得时候我抓狂了，因为我需要在每个使用邮件开发包的类的地方加入“如果链接这个邮件服务器失败，则链接另一个”，好一通找。赶紧封装到工厂里。。对于外来得，自己并不熟悉得开发包，使用工厂等价于给自己对这个包可能得任何不理解得地方的空间。

IOC提出的前提，Martin Folwer是这样阐述得，IOC是为了构建web层的可插拔组件而提出得，因为众所周知，人人都想把软件做成零件拼装得形式，可是web项目出于“环境依赖性强”得特点，构件可插拔性弱，IOC致力于解决这个矛盾。

一般工厂和IOC是可以同时使用得。

以上我的见解

在实际的项目应用中，数据库的移植是不常见的，基本上没有见过。 如果出现数据库移植，程序的改动是相当大的，不是简单的改变下factory的调用就能完成的。
这种抽象工厂的做法只是作为一种技术存在在spring这种框架中。
性能这方面，没有具体研究不好说。[/quot

数据库是可移植也取决于持久层接口的设计好坏，比如如果Dao有，find（String sql）这样的方法，显然是破坏移植性的，因为开发人员完全有可能传进去一个只有oracle才能执行得语句。。所以除了考虑factory以外，注意接口的设计

企业开发一般都用DataSource，根本不需要Class.forName()什么的。

如果用DAO也是封装到EJB里，要换DAO的话换个JNDI就可以了。

用了Hibernate或OpenJPA之后，如果设计得当的话，数据库之间的差异可以忽略不计。

切换数据库不仅仅是运行起来的程序今天用MySql明天用Oracle.
还要保证你的程序对A用户可以用MySql，对于B用户可以用Oracle.
如果开发的程序只有一个人用,也没多少地方天天换.

暂且先不要谈Spring IOC,就楼主的本意来谈谈到底应该不应该使用抽象工厂吧
我们老大也让我给做一个通用的IDAO出来以应付多个数据源切换的要求,虽然说一般情况下一个项目更换数据源的可能性非常小,但是这么做的目的其实是为了统一DAO操作接口,更重要的目的是为了在DAO层面上事先不同数据源的事务管理