DAO和服务？

Question

我总是面临一个问题,我无法真正想到封装了许多DAO方法的服务对象.

我的意思是,对于我的servlet,有时使用单个DAO方法就足够了,例如addUser(User params).

更好的做法是 - 使用服务对象封装DAO方法并仅使用服务对象,即使它实际上意味着单个服务方法调用单个dao方法或将它们的使用混合在一起(来自服务对象的一些方法和来自servlet中的dao的一些方法)上下文) - 意味着我在控制器内部自动装配了DAO和Service对象？

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

Answer 1

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

但是,如果您的DAO是"虚拟"并且只调用EntityManager方法,则可以直接在服务对象中使用它.我们的想法是让课程具有单一职责,并且易于扩展和测试.你不应该为它创建图层.

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

Answer 2

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

其中之一就是那句古老的“你不会需要它”。在需要之前不要实施某些东西。只是因为您预见到某些原因需要额外的间接层来执行一些额外的逻辑，所以不确定您是否需要它。当您最终需要它时，您可能会发现您的期望与您之前的信念并不相符。而且您会付出额外的成本，因为现在您必须对两个类而不是一个类进行单元测试，并且需要在两个位置而不是一个位置添加方法的情况并不罕见。

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

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