8

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

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

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

提前致谢！

4

3 回答 3

2

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

于 2012-07-10T16:09:05.957 回答
1

我看到了第四个原因：

  • 隐藏实施细节

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

于 2012-07-04T08:25:59.337 回答
0

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

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

于 2012-07-10T19:08:47.393 回答