DAO 和服务？
我总是面临一个问题，我无法真正想到封装许多 DAO 方法的服务对象。
我的意思是，对于我的 servlet，有时使用单个 DAO 方法就足够了，例如 addUser(User params)。
更好的做法是用服务对象封装 DAO 方法并始终只使用服务对象，即使它字面意思是单个服务方法调用单个 dao 方法或将它们混合使用（一些方法来自服务对象，一些方法来自 servlet 中的 dao） context) - 意味着我在控制器内有自动连接的 DAO 和服务对象？
如果我开始在同一个地方使用 DAO 和 Service 对象，它会混淆逻辑吗？
I'm always facing a problem where I can't really think of service object encapsulating many DAO methods.
I mean that for my servlet sometimes it is sufficient to use single DAO method, for example addUser(User params).
What is better to do - to encapsulate DAO methods with service object and use only service objects ALWAYS, even if it literally means a single service method calling single dao method or mixing their use together(some methods from service objects and some from dao in servlet context) - meaning that I have autowired DAOs and Service objects inside controller ?
It mixes up the logic if I start to use both DAO and Service object in the same place?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为这个要看具体情况。如果没有 DAO 会导致业务逻辑和数据访问逻辑混合，那么最好有单独的类。
但是，如果您的 DAO 是“虚拟”的并且仅调用 EntityManager 方法，则您可以直接在服务对象中使用它。我们的想法是让类具有单一职责并且易于扩展和测试。您不应该为此而创建图层。
如果您想保留可重用的服务层，我可能不会直接从控制器使用 DAO。如果 DAO 没有意义，我宁愿在服务层中使用 EntityManager（或您正在使用的任何持久性策略）。
I think this depends on the situation. If not having a DAO is going to cause mixing your business logic and your data access logic, it is probably better to have separate classes.
However, if your DAO is "dummy" and just calls an EntityManager method, you can probably use this directly in your service objects. The idea is to have classes that have single responsibilities and are easy to extend and test. You shouldn't be creating layers for the sake of it.
I probably wouldn't use DAOs directly from your controllers if you want to keep a reusable service layer. I would rather use the EntityManager (or whatever persistence strategy you are using) in the service layer if the DAO doesn't make sense.
我正在使用一个“你不能让控制器与 DAO 交互！”的系统。设计理念在某个时刻被接受，并为每个组件创建了一个服务层。正如您所描述的，大多数服务只是委托给 DAO。我反对这种哲学有两个原因。
其中之一就是那句古老的“你不会需要它”。在需要之前不要实施某些东西。只是因为您预见到某些原因需要额外的间接层来执行一些额外的逻辑，所以不确定您是否需要它。当您最终需要它时，您可能会发现您的期望与您之前的信念并不相符。而且您会付出额外的成本，因为现在您必须对两个类而不是一个类进行单元测试，并且需要在两个位置而不是一个位置添加方法的情况并不罕见。
第二个问题是，服务到底是什么？当我对我的领域进行建模时，我尝试用面向对象的术语进行思考。有用户，因此 User 类才有意义。有新闻项，因此 NewsItem 类有意义。但我什至不知道 UserService 应该做什么。包含用户的“业务逻辑”？不，这就是 User 类的用途。
如果您需要对“外部世界”维护严格的 API，那么我可以看到有一个保持不变的额外层的情况。但在所有其他情况下，您都不需要它。
I am working with a system where the "you cannot have the controllers interact with the DAOs!" design philosophy was embraced at a point and a service layer was created for every component. Most of the services are, as you describe, simply delegating to a DAO. I object to this philosophy for two reasons.
One is the good old "You aren't gonna need it". Don't implement something until you need it. Just because you foresee some reason to have an extra layer of indirection to do some extra logic, it's not sure you're going to need it. And when you end up needing it, you will probably find out that your expectations didn't really match what you believed earlier. And you get an extra cost, because now you have to unit test two classes instead of one, and it's not uncommon that you need to add methods in two places instead of one.
The second is, what the heck is a service anyway? When I model my domain, I try to think in object-oriented terms. There are users, therefore the User class makes sense. There are news items, therefore the NewsItem class makes sense. But I don't even know what a UserService is supposed to do. Contain "business logic" for users? No, that's what the User class is there for.
If you need to maintain a strict API to the "outside world", then I can see a case to have an extra layer that remains unchanged. But in all other cases, you aren't going to need it.
就我个人而言，我通常将 DAO 调用封装在服务中。
这允许我使用 AOP 等使所有服务成为事务性的。并在这些服务中使用非事务性 DAO 方法。
对于琐碎的服务，这是一个额外的“层”，但在我看来，这是一个服务于某种目的的层（并且无论如何都可以使用一种或另一种代码生成来生成它）。不过，我也很少将 DAO 功能封装在服务中。
Personally, I usually encapsulate DAO calls within services.
This allows me to make all services transactional using AOP/etc. and use non-transactional DAO methods within those services.
For trivial services, this is an additional "layer", but IMO one that serves a purpose (and code generation of one sort or another can be used to generate it anyway). It's also rare I have only DAO functionality wrapped up in a service, though.
视情况而定。将 DAO 和服务层分开的原因通常是：
使用 Java EE 6（JBoss AS 7），我没有这些负担：
所以我在DAO层有大部分方法。
对于某些情况，更复杂的操作，我创建一个服务 bean，并且可能使用 扩展持久性上下文。
我的经验法则是，一个方法是否应该进入 Service bean：
Depends. The reasons to separate DAOs and Service layer are often:
Using Java EE 6 (JBoss AS 7), I don't have these burdens:
So I have most methods in DAO layer.
For some cases, more complex operations, I create a service bean and perhaps use an extended persistence context.
My rule of thumb, whether a method should go into a Service bean: