仅创建服务层和DAO层（接口+实现）或实现

Question

我对创建服务图层和 DAO 图层的结构感到困惑： 在某些示例中，我看到有些人为服务和DAO创建接口+实现，在其他示例中，我看到人们在DAO扩展 AbstractDao时特别创建仅实现 这些DAO包含泛型方法的类，所以我很困惑该怎么做，为什么选择这个解决方案或者另一个解决方案，以及最佳实践（常用方法）请告知。

Answer 1

我建议为服务和DAO创建接口。通常，您希望在使用此服务的代码的单元测试中模拟服务。 例如，Spring在您使用某些Spring代理（例如事务）时强制您使用接口。所以你应该有一个服务接口。

DAO是更内部的部分，但我总是尝试使用接口来简化测试。

Answer 2

我更喜欢接口+实现，原因如下：

• 接口变为合同：它们告诉您可以调用的内容，如果预期结果，您永远不会担心其实现。
• 您可以创建界面的可自定义实现，而不会破坏同一界面的其他实现（在编写单元测试时通常很有用）。自定义仅实现的类可能会带来比您不容易注意到的更多错误。
• 它创建了一个可以记录的框架。

已实现的子类用于创建符合接口契约的业务/应用程序逻辑。

Answer 3

我只完成了服务层的实现，没有打扰接口（除了我必须的地方）。我可能应该编写接口，但到目前为止没有问题。我正在进行单元测试，没有模拟服务层。

另外，我没有DAO层，因为我正在使用hibernate，它似乎有点过分。我的很多推理都基于这个博客eloquently written by Bozho。

我认为它是quite debatable（无论是否有DAO和hibernate），但我对我的决定非常满意，我传入了厚域对象，然后只调用hibernate会话。 dao层上的每个方法实际上只是一行（session.persist（mObject）或类似的）。

我听到的一个论点是dao图层可以让以后更容易更改/删除orm。我不确定在第一个位置编码dao层所花费的时间是否会增加到编码更改的时间，而不是编码没有dao层的更改。我从未在任何工作地点改变ORM技术，因此风险很小。

Answer 4

从我的观点来看，当您说 服务 时，您应该有接口，如果您不能提供或不提供接口，那么您没有服务和消费者之间的合同，它不再是服务，你可以称之为其他任何东西

Answer 5

使用接口+实现以便具有松散耦合。您可以轻松地更改或切换实现，而无需对代码进行重大更改。

考虑一下你正在使用Hibernate进行持久化（DAO Layer）的场景，你需要切换到JPA或iBatis或任何其他ORM。

如果您正在使用接口，您可以简单地编写一个特定于JPA的实现，并“插入”它来代替Hibernate。服务代码保持不变。

Answer 6

接口+实现模型的另一个论点是Java本身支持接口的代理，而为实现创建代理则需要使用诸如 cglib 之类的库。此代理对于事务支持等是必需的。

Answer 7

查看我关于“fastcode”的帖子，这是一个eclipse-spring插件，可以从你的DAO中生成服务层。奇迹般有效。 generate service /dao layer for GWT/Spring/Hibernate/PostgreSQL