我对创建service层和DAO层的结构感到困惑： 在某些示例中，我看到有些人为服务和 DAO 创建 interface+implementation，而在其他示例中，我看到人们在 DAO 扩展 AbstractDao 时创建 implementation only 类包含这些 DAO 的 通用方法，所以我很困惑要做什么，为什么要选择这个解决方案或另一个解决方案，以及最佳实践是什么（常用) 请指教。
【问题讨论】：
标签： java oop jakarta-ee structure
我建议为服务和 DAO 创建接口。很多时候，您想在使用此服务的代码的单元测试中模拟服务。 例如，当您使用某些 Spring 代理（例如用于事务）时，Spring 也会强制您使用接口。所以你应该有一个服务接口。
DAO 更多是内部部分，但我总是尝试为它们使用接口来简化测试。
【讨论】：
我更喜欢接口+实现，原因如下：
实现的子类用于创建符合接口契约的业务/应用程序逻辑。
【讨论】：
我只完成了服务层的实现，没有打扰接口（除非我必须这样做）。我可能应该开始编写接口，但到目前为止没有问题。我在没有模拟服务层的情况下进行单元测试。
另外，我没有 DAO 层，因为我使用的是 hibernate，这似乎有点矫枉过正。我的很多推理都是基于这个博客，eloquently written by Bozho。
我认为是quite debatable（是否有 DAO 和休眠），但是我对我的决定很满意，我传入厚域对象，然后调用休眠会话。 dao 层上的每个方法实际上只有一行（session.persist(mObject) 或类似的）。
我听到的一个反对意见是，dao 层可以让以后更容易更改/删除 orm。我不确定是否首先花费在对 dao 层进行编码的时间加上对更改进行编码的时间，是否会少于在没有 dao 层的情况下单独对更改进行编码。我从来没有在我工作过的任何地方改变 ORM 技术，所以风险很小。
【讨论】：
从我的角度来看，当您说 Service 时，您应该有接口，如果您不能提供或不会提供，那么您就没有服务和消费者之间的合同，它不再是服务，你可以叫它任何东西
【讨论】：
使用接口+实现是为了实现松耦合。您可以灵活地轻松更改或切换实现，而无需对代码进行重大更改。
想一想您使用 Hibernate 进行持久性（DAO 层）的场景，您需要为此切换到 JPA 或 iBatis 或任何其他 ORM。
如果您使用接口，您可以简单地编写一个特定于 JPA 的实现并“插入”它来代替 Hibernate。服务代码保持不变。
【讨论】：
interface+implementation 模型的另一个论点是，Java 本身支持接口的代理，而为实现创建代理需要使用诸如 cglib 之类的库。并且这个代理对于事务支持等是必要的。
【讨论】：
查看我关于“fastcode”的帖子，这是一个 eclipse-spring 插件，可从您的 DAO 生成服务层。奇迹般有效。 generate service /dao layer for GWT/Spring/Hibernate/PostgreSQL
【讨论】：