我们有一个典型的 n 层 java 应用程序，我注意到我们的数据访问层具有 FooDAO 和 FooDAOImpl 类型的 DAO。我一直在寻找证明这两者的必要性的理由，这是我的分析。
- 如果您对同一个接口(interface)有多个实现，那么抽象是有帮助的。但是鉴于我们已经选择了用于 DAOImpl 的框架(比如 iBATIS)，是否真的需要它？
- 帮助通过 Spring 进行代理。据我所知，具有接口(interface)的类可以很容易地被代理(走 JdkProxy 路线)，而不是没有接口(interface)的类(选择 cglib 路线)，并且一个具有要被代理的类的子类。子类化有它的问题，即要代理的类是最终类或没有默认构造函数——这两种情况在数据访问层都不太可能发生。性能曾经是一个因素，但据我所知，它不再是一个问题。
- 帮助模拟。具有接口(interface)的类更适合被模拟框架模拟。我只听说过，但没有在实践中看到它 - 所以不能真正指望它，但可能是因为与上面 #2 中提到的相同的因素。
鉴于这些要点，我觉得不需要单独的 FooDAO 和 FooDAOImpl，一个简单的 FooDAO 就足够了。请随时更正我提到的任何要点。
提前致谢!
最佳答案
我用 Mockito 尝试了#3，它能够很好地模拟没有接口(interface)的 POJO。鉴于针对#1 和#2 提到的论点，我暂时倾向于不使用单独的 DAO 和 DAOImpl。随意添加其他比较点。
关于java - DAO 需要单独的接口(interface)和实现，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11323190/