DAO package structure答案

【问题标题】：DAO package structureDAO package structure
【发布时间】：2012-04-16 09:35:21
【问题描述】：

我正在使用 JDBC（没有 Spring、Hibernate 或其他任何东西）在 Java 中编写一些简单的 DAO。

将实现 DAO 与其接口放在同一个包中还是将它们放在子包中更好？

例子：

com.mycompany.myproject.dao.MyDao
com.mycompany.myproject.dao.MyDaoImpl

或

com.mycompany.myproject.dao.MyDao
com.mycompany.myproject.dao.impl.MyDaoImpl

如果您建议子包结构，您会建议子包名称是什么？ .impl？ .sql？ .jdbc？

实际上，我不会有多个实现。我是否过度设计了这个？

【问题讨论】：

标签： java dao

【解决方案1】：

在设计应用程序时，没有标准包的结构方式，经验通常可以帮助每个人确定我们的包的合适名称。

关于将接口的实现打包在同一个包或不同包中，只需考虑 Java 本身的结构：通常一个实现类与其接口被打包在同一个包中，但并非总是如此。

如果您将拥有相同 DAO 的多个实现，那么将它们构建在 .jdbc、.jpa 或 .jdo 子包中是有意义的。如果您只打算有一个实现，那么您列举的两个选项在某种程度上都是有意义的（相同的包或.impl 子包）。

关于过度工程，我会向您推荐这个article。即使您将只有一个 DAO 的实现，将它们定义为接口和实现也是有意义的，因为这将帮助您在未来为其他框架重写您的 DAO，同时使用的代码它们保持不变。

最终取决于您（或您和您的同行）达成共识并做出对您的具体情况更有意义的决定。

编辑

应用程序通常每个 DAO 接口都有一个实现，这根本没有过度设计，为 JPA 和 JDO 实现相同的 DAO 接口根本没有意义。使用接口/实现模式的一些目的是简化重构、通过模拟对象进行测试等。

P.S.：我通常依靠 JDepend 将我的应用程序类分发到包中，尽可能避免循环。

【讨论】：

标准的方法是把它分开。任何架构师都会通过将它们放在同一个包中来指出您面临的问题。最终，您的代码会在您没有意识到的情况下变得非常臃肿且不可分割。当您编写代码时，这一切看起来都很小，但应该在编写代码时牢记未来的扩展和管理。
感谢您的洞察力，我认为这个答案现在已经过时了，老实说，我永远不会组织代码如何 OP，这个答案，或者你建议，因为所有这些都忽略了凝聚力和功能块的模块化，不管每个模块可以使用 JDO 或 DynamoDB 彼此独立的事实。这就是使代码可分割的实际问题，而不是将相同颜色的袜子放在同一个抽屉里。

【解决方案2】：

我认为两者都不是更好，但在这种情况下，我更喜欢第一种选择。它将与 ArrayList、LinkedList 等与 List 在同一包中一致。

当使用额外的框架时，例如hibernate，我更喜欢使用MyDao 和HibernateDao 作为实现者的第二个选项。

【讨论】：

【解决方案3】：

我会选择您的第二个选项（尽管没有一个更好），因为如果导入了 impl，您可以立即在导入中看到，如果您想将 impl 移动到另一个项目中，重构会更简单。

这不是过度设计。使用 DAO 有多种优势：

【讨论】：

这应该是公认的答案。我们不仅要从代码的角度思考，还要从封装的角度思考。我们目前正在将单体架构转换为微服务，我们面临的最大问题是接口和实现类都放在同一个包中。使用互联网上的一些工具，您可以通过在开始时不分离这些东西来检查您的整个项目有多胖。

【解决方案4】：

命名空间和包的存在只是为了防止冲突。只要它们是独一无二的，两者都不是可取的。

【讨论】：

所以可以将你的包命名为长的、随机的字符串吗？合理的包名称使人们更容易浏览您的 API，并使重构更容易。此外，例如分离在包指定导出和依赖项的环境中，实现和接口是一种很好的做法，因为您通常只想依赖接口或实现。
我的回答是针对 OP 的案例。他/她提出的备选方案之间没有客观差异。关于您的评论，我只能说创建一个可理解的命名空间是常识。

【解决方案5】：

包的一个目的是提高团队中其他程序员的可读性。通常，我将实现与接口放在同一个包中，因为那是显而易见的地方，而且在大多数情况下，DAO 实现很简单。如果您的实现很复杂，那么您应该找到适合您的应用程序的框架。

考虑单独包的其他原因包括：如果您正在编写一个将被其他组使用的库，或者如果您想要支持多种实现。

【讨论】：