关于 DAO 的正确使用(取两个)
是否可以说,当您将一个 DAO 注入另一个 DAO 时,您就已经超出了 DAO 范围,并到达了业务层问题?
注意:我并没有考虑特定的问题,只是试图提取有关 DAO 使用的一般经验法则。
Could it be said that when you reach the point of injecting one DAO into another one, you've already gone over the DAO scope, and reached a business layer issue?
NOTE: I am not having a particular issue in mind, but just trying to extract a general rule of thumb regarding the use of DAOs.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
DAO 和 Business 之间的划分是“任意的”。当一个类用于“从存储库检索和存储数据”时,我们称该类为 DAO。事实上,您将一个 DAO 注入另一个 DAO 中并不会阻止它“从存储库中检索和存储数据”,所以对我来说,您问题的答案是否定的。
没有任何地方说不能将 DAO 注入另一个 DAO(尽管通常不会这样做)。
The division between DAO and Business is "arbitrary". We say that a class is a DAO when it is used to "retrieve and store data from storage repositories". The fact that you inject a DAO in another DAO doesn't prevent it to "retrieve and store data from storage repositories", so for me the answer to your question is NO.
There is nowhere said that you cannot inject a DAO into another (even though it is not usually done).
是的。 DAO 不应相互依赖。
协调不同的 DAO 是业务/服务层的工作。
但是,如果您描述您的具体情况,我们将能够给出更准确的答案。
编辑:
阅读@edutesoy 的回答后,我明白了他的论点的逻辑。
因此,我将通过说来完善我的答案 - 这样做本质上并不是错误的,但它有点“臭”。
这是因为 DAO 层的正常结构 - 通常每种类型的实体都有一个 DAO(
CustomerDAO
、OrdersDAO
等)。如果您的CustomerDAO
使用您的PaymentsDAO
,这听起来有点像违反 SRP:CustomerDAO
还负责与支付相关的操作吗?< br>所以,总而言之,在将其引入我的代码之前,我肯定需要一个很好的理由。
Yes. DAOs shouldn't be dependent on each other.
It's the job of the business / service layer to coordinate different DAOs.
However, if you'd describe your specific scenario we would be able to give a more accurate answer.
Edit:
After reading @edutesoy's answer, I see the logic in his argument.
So I'll refine my answer by saying- it's not inherently wrong to do that, but it is a little 'smelly'.
This is because of the normal structure of your DAO layer- you usually have a DAO for each type of entity (
CustomerDAO
,OrdersDAO
etc) . If yourCustomerDAO
is using yourPaymentsDAO
, it smells a bit like a violation of SRP: isCustomerDAO
responsible also for payments-related operations?So, in conclusion- I would definitely require a very good reason for this before introducing it into my code.
也许您应该首先思考什么是 DAO。
如果您使用 JPA,那么实体管理器已经是一个通用的 DAO(通过 DAO 模式)。大多数 Java EE 开发人员所说的 DAO 并不是 DAO by DAO 模式。这是某种重构:将与数据库相关的语句移出到外部类中(我认为这就是您正在谈论的 DAO 类型)别误会我的意思,我认为这很有用。
所以我对这个 DAO 的理解是一些重构的东西。重构的总体目标是使代码更具可读性、可维护性。因此,如果您的代码通过这种间接方式变得更好,那么请继续,但您应该记录您的项目 DAO 模式与其他 Java EE 开发人员使用的 DAO 模式略有不同。
May you should start with thinking of what a DAO is.
If you use JPA, then the entiy manager is already a generic DAO (by DAO Pattern). What the most Java EE developer call a DAO is not a DAO by DAO Pattern. It is some kind of refactoring: move out the Database related statements into an external class (and I think that is the kind of DAO you are talking about) Don't get me wrong, I think this is usefull.
So my understanding of this DAO is some refactoring thing. And the overall goal of refactoring is making the code more readable, maintainable. So if you code becomes better with this indirection then go on, but you should document that your project DAO-Pattern is slightly different from the DAO Pattern used by may other Java EE Developers.