服务和DAO之间的关系应该是一对一还是一对多？

Question

引发这个问题的代码是我公司代码库中的一个服务,其中包含四个不同的DAO.在我看到这个服务已经与属于完全不同的服务的方法混淆之前,我没有想太多.在此服务中创建这些无根据的方法的原因仅仅是因为所需的DAO是此Service类的私有成员.

这个开发人员是不正当的,或者在大多数情况下每个服务类有多个DAO是不对的？

注意:我注意到每个Service类有多个DAO似乎是合理的,只要它们都包含在同一个数据库中.但是从多个数据库中获取DAO似乎可能会导致问题.

Answer 1

我发现每个服务类有多个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来完成任务.

希望这个解释有所帮助

Answer 2

只要分解 DAO 有意义，一对多就可以。

我认为拆分 DAO 有意义的几个原因：

• 不同的数据库。如果您正在处理帐户和销售数据库，您可能希望将 DAO 分为 SalesDAO 和 AccountingDAO。这将使维护更加容易。
• 重复使用。您可能有一些可以在多个地方重用的方法，并且仅将这些方法分开将可以更好地重用。