DAO 需要单独的接口和实现答案

【问题标题】：Need for separate interface and impl for DAODAO 需要单独的接口和实现
【发布时间】：2012-07-04 14:37:57
【问题描述】：

我们有一个典型的 n 层 java 应用程序，我注意到我们的数据访问层具有 FooDAO 和 FooDAOImpl 类型的 DAO。我正在寻找证明两者的必要性，这是我的分析。

如果您对同一个接口有多个实现，那么抽象很有帮助。但鉴于我们已经选择了用于 DAOImpl（比如 iBATIS）的框架，真的需要吗？
帮助通过 Spring 进行代理。据我所知，具有接口的类可以很容易地代理（使用 JdkProxy 路由），而不是没有接口的类（选择 cglib 路由），并且一个类具有要代理的类的子类。子类化有它的问题，即要代理的类是最终的或没有默认构造函数——这两种情况在数据访问层都是极不可能的。性能曾经是一个因素，但据我所知，它不再是一个令人担忧的原因。
帮助模拟。具有接口的类更适合被模拟框架模拟。我只听说过这个，但没有在实践中看到过 - 所以不能真正指望它，但可能是因为与上面 #2 中提到的相同因素。

有了这些观点，我觉得不需要单独的 FooDAO 和 FooDAOImpl 一个简单的 FooDAO 就足够了。请随时纠正我提到的任何问题。

提前致谢！

【问题讨论】：

除非我弄错了，否则您实际上不会在这里提问吗？您的“问题”中已经说明了使用带有注入的接口的好处......
是的，您已经陈述了使用 DAO 接口和实现的三个充分理由。我会得出与你相反的结论，即需要有一个接口！
@user935439 问题在每个要点中。虽然我们原则上同意接口的好处，但我想就减少我必须编写和维护的类文件的兴趣收集意见，当接口在这种用例中的好处不完全明显时。您是否通过示例知道当您涉及接口时模拟是否更容易？谢谢！
看看 mockito 或 easymock 框架。它从接口生成模拟对象，所以我想接口在这里是至关重要的

【解决方案1】：

我用 Mockito 尝试了#3，它能够在没有接口的情况下模拟 POJO。由于反对#1 和#2 的论点，我倾向于暂时不使用单独的DAO 和DAOImpl。随意添加其他比较点。

【讨论】：

【解决方案2】：

我看到了第四个原因：

例如取决于团队、软件的预期生命周期或未来预期的更改量，即使只有一个实现，也应尽可能隐藏。

【讨论】：

【解决方案3】：

我会说拥有一个 FooDAO 接口和单个实现 FooDAOImpl 通常是一种反模式。更简单的解决方案（DAO 没有单独的接口）更可取，除非您有充分的理由 - 这似乎不是这里的情况。

就个人而言，我会更进一步地说，拥有 DAO 根本不是最佳选择。我更喜欢在诸如 Hibernate 或 JPA 之类的 ORM API 之上实现单个持久性外观类。不过，也许 iBATIS 太低级了。

【讨论】：