服务和 DAO 之间的关系应该是一对一还是一对多？
引发这个问题的代码是我公司代码库中的一个服务，其中包含四个不同的 DAO。我没有多想这一点，直到我看到该服务已与属于完全不同的服务的方法混为一谈。在该 Service 中创建这些无根据的方法的原因很简单，因为所需的 DAO 是该 Service 类的私有成员。
这是开发人员的渎职行为，还是在大多数情况下每个服务类拥有多个 DAO 是错误的？
注意：我注意到，每个服务类拥有多个 DAO 似乎是合理的，只要它们都包含在同一个数据库中。但从多个数据库中获取 DAO 似乎可能会导致问题。
The code that sparked this question was a Service in my company's code base that contained four different DAO's. I didn't think much of this until I saw that this Service had become conflated with methods that belonged in a completely different Service. The reason for the creation of these unwarranted methods inside this Service was simply because that the needed DAO's were private members of this Service class.
Is this developer malpractice, or is it wrong in most cases to have more than one DAO per service class?
Note: I noticed that it seems reasonable to have more than one DAO per Service class as long as they are all contained within the same database. But having DAO's from multiple databases seems like it may cause issues.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为每个服务类拥有多个 DAO 并没有什么问题。多年前，当我第一次开始进行 Web 开发时，我只有一个服务一个 DAO，因为这似乎是最合乎逻辑、最直接的方法。然后，我开始发现服务不同服务的 DAO 之间存在类似 API 的问题。因此，我的“不成熟”解决方案是将这些通用 API 推广到某些父 DAO，以便由这些 DAO 继承。当项目增长时，继承已经不再有意义，因为我遇到过这样的情况：80% 的子 DAO 需要该 API，但 20% 不需要，但它们仍然从同一个父级继承DAO 因为它们共享其他类似的 API。你看到这里的问题了吗？我的意思是，在 Java 中，你只能从一个父级继承，所以我最终在父级 DAO 中填充了“可能”被“大多数”DAO 使用的 API，这从一开始就完全违反了继承原则。
现在，我的所有 DAO 类都有特定的职责/任务。一个 DAO 可以调用另一个 DAO（例如，大多数 DAO 使用 LoggingDAO 来记录用户操作）。这样，DAO 就不会提供一个服务于特定服务的 DAO，而是会提供可能使该服务受益的操作列表。该服务将“使用”任何 DAO 来完成任务。
希望这个解释有帮助。
I see nothing wrong having multiple DAOs per service class. When I first started doing web development many years ago, I had one service one DAO because that seemed to be the most logical and most straightforward approach. Then, I began seeing issues where there are similar APIs among DAOs serving different services. So, my "immature" solution was to promote these common APIs to some parent DAO to be inherited by these DAOs. When the project grows, it has come to a point where inheritance doesn't make any sense anymore, because I have situations where 80% of the children DAOs need that API but 20% don't, yet they still inherit from the same parent DAO because they share other similar APIs. You see the problem here? I mean, in Java, you can only inherit from one parent, so I ended up stuffing APIs that "might" be used by "majority" of the DAOs in the parent DAO, which completely violates the principle of inheritance in the first place.
Right now, all my DAO classes have specific responsibilities/tasks. It is okay for a DAO to call another DAO (for example, LoggingDAO is used by most DAO to log user actions). This way, instead of having one DAO that serves a specific service, the DAO provides a list of operations that may benefit the service. The Service will "use" whatever DAOs that will it to accomplish the task.
Hope this explanation helps.
只要分解 DAO 有意义，一对多就可以。
我能想到分割 DAO 的几个原因：
One to many is fine as long as it makes sense to break up the DAOs.
A couple of reasons I can think of where it makes sense to split a DAO:
在我工作过的一家公司，他们有一个很好的设计，其中服务称为控制器，控制器可以调用另一层，我不记得了，但那会调用 DAO。
所以，他们有一个可以调用多个DAO的访问级别，以便执行更高阶的功能，所以，如果你想做一个订单，可能需要调用多个表，甚至可能需要调用多个系统，所以控制器会调用
doOrder方法。这是一个很好的设计，因为它保持了良好的分离感，并使单元测试更简单，因为您可以测试每一层。
如果您的服务能够调用多个 DAO，那么单元测试可能会更加困难，因为您使服务层变得更加复杂。
因此，当您设计层时，请考虑创建新层来简化设计是否有意义，这可能会发现错误或防止错误。
更新：
缺少的层是协调器，规则是每个协调器处理一个 DAO，并且可以执行所需的任何转换，但业务逻辑位于控制器中。因此，协调员可以与任何其他协调员交谈以获取信息，然后这些协调员将前往 DAO。
At one company I worked at, they had a nice design where the service called a controller, and the controller could call another layer, which I can't remember, but that would then call the DAO.
So, they had an access level that could call multiple DAOs, in order to do a higher-order functions, so, if you want to do an order, it may require calling multiple tables, and perhaps several systems, so the controller would call the
doOrdermethod.This is a nice design as it keeps a good sense of separation and made unit testing simpler, as you can test each layer.
If your service is able to call multiple DAOs then unit testing may be harder, as you make the service layer more complicated.
So, when you are designing your layers, look at whether it makes sense to create new layers to simplify designs, which may uncover bugs or prevent bugs.
UPDATE:
The missing layer was the coordinator, and the rules were that each coordinator dealt with one DAO, and could do any transformations that were needed, but business logic was in the controller. So, a coordinator could talk to any other coordinator, to get information, and those coordinators would go to the DAO.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
DAO 的数量完全取决于底层来源！
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html
The amount on DAO's simply depends on the underlying sources !