java需要为DAO提供单独的接口和impl

Question

我们有一个典型的n层java应用程序，我注意到我们的数据访问层有类型为FooDAO和FooDAOImpl的DAO。我想证明这两种方法的必要性，下面是我的分析

1. 如果您对同一接口有多个实现，那么抽象将非常有用。但是考虑到我们已经选择了用于DAOImpl（比如iBATIS）的框架，它真的是必需的吗
2. 帮助通过Spring代理。从我收集的信息来看，有接口的类可以很容易地被代理（通过JdkProxy路由），而不是没有接口的类（选择cglib路由），并且一个类具有要代理的类的子类。子类化有它的问题，其中要代理的类是final或没有默认构造函数——这两种情况在数据访问层非常不可能发生。性能曾经是一个因素，但据我所知，它不再是一个值得关注的问题
3. 帮助嘲笑。具有接口的类更适合由模拟框架进行模拟。我只听说过这一点，但在实践中没有看到过——因此我不能真正相信这一点，但可能是因为上面第2节提到的相同因素

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

提前谢谢

Answer 1

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

Answer 2

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

就我个人而言，我会更进一步地说，拥有DAO根本不是最好的选择。我更喜欢在ORMAPI（如Hibernate或JPA）之上实现一个持久化门面类。不过，也许iBATIS的水平太低了

Answer 3

我看到了第四个原因：

• 隐藏实现细节

例如，根据团队、软件的预期寿命或未来预期的更改量，尽可能多地隐藏是值得的，即使只有一个实现