DAO和服务？

Question

我总是遇到一个问题，我无法真正想到封装了许多DAO方法的服务对象。

我的意思是，对于我的servlet，有时使用单个DAO方法就足够了，例如addUser（User params）。

最好做什么 - 用服务对象封装DAO方法并且只使用服务对象，即使它实际上意味着调用单个dao方法或将它们的使用混合在一起的单个服务方法（来自服务对象的一些方法和来自服务对象的一些方法）在servlet上下文中的dao） - 意味着我在控制器中有自动装配的DAO和Service对象？

如果我开始在同一个地方同时使用DAO和Service对象，它会混淆逻辑吗？

Answer 1

我认为这取决于具体情况。如果没有DAO会导致混合业务逻辑和数据访问逻辑，那么最好有单独的类。

但是，如果您的DAO是“虚拟”并且只是调用EntityManager方法，则可以直接在服务对象中使用它。我们的想法是拥有single responsibilities的类，并且易于扩展和测试。你不应该为它创建图层。

如果您想保留可重复使用的服务层，我可能不会直接从您的控制器使用DAO。如果DAO没有意义，我宁愿在服务层使用EntityManager（或者你正在使用的任何持久性策略）。

Answer 2

我正在使用一个系统，其中“你不能让控制器与DAO交互！”设计理念在某一点上被接受，并且为每个组件创建了服务层。正如您所描述的，大多数服务只是委托给DAO。我反对这一理念有两个原因。

一个是好老“你不会需要它”。在您需要之前不要实施某些东西。只是因为你预见到某种原因需要额外的间接层来做一些额外的逻辑，所以你不确定你是否会需要它。当你最终需要它时，你可能会发现你的期望与你之前认为的不符。而且你得到了额外的费用，因为现在你必须对两个类进行单元测试而不是一个，并且你需要在两个地方而不是一个地方添加方法并不罕见。

第二个是，到底是什么服务？当我为自己的域建模时，我会尝试用面向对象的术语来思考。有用户，因此User类是有道理的。有新闻项，因此NewsItem类是有道理的。但我甚至不知道UserService应该做什么。包含用户的“业务逻辑”？不，这就是User类的用途。

如果你需要为“外部世界”维护一个严格的API，那么我可以看到一个案例，让一个额外的层保持不变。但在所有其他情况下，你根本不需要它。

Answer 3

就个人而言，我通常在服务中封装DAO调用。

这允许我使用AOP /等进行所有服务交易。并在这些服务中使用非事务性DAO方法。

对于普通服务，这是一个额外的“层”，但IMO服务于一个目的（无论如何，可以使用一种或另一种代码生成来生成它）。但是，我很少将仅 DAO功能包含在服务中。

Answer 4

取决于。分离DAO和服务层的原因通常是：

• 技术限制（参见其他答案中的AOP交易）
• 架构约束（DTOs＆lt; =＆gt;服务层和DAO之间的@Entities转换）
• 历史（这是X年的工作方式）
• esthetical（仅从视图层访问一个图层）

使用Java EE 6（JBoss AS 7），我没有这些负担：

• 没有AOP - @Stateless和@Transactional负责交易。
• 没有DTO - 我使用JPA的@Entities直到视图层。
• 不关心历史。
• 我更喜欢简单/更少的代码而不是美学。

所以我在DAO层中有大多数方法。 对于某些情况，更复杂的操作，我创建了一个服务bean，并且可能使用extended persistence context。

我的经验法则是，方法是否应该进入Service bean：

1. 如果它使用多个DAO（显然）
2. 如果它执行多个实体管理员调用
3. 如果实施可能会改变，例如在JPQL与Hibernate Search与ElasticSearch进行搜索。