java在dao端使用逻辑不是一个好的实践吗？

Question

我有实体A，而A有一组实体B。我偷懒加载。当我加载所有的A结果列表时，我需要为每个A具有B大小的A设置一个临时值

在服务层，我不能这样做，因为我执行了延迟加载。我必须在dao端设置瞬态值。但我听说在{}方面没有逻辑

我该怎么办？如有任何解释，我们将不胜感激

Answer 1

如果查看Hibernate count collection size without initializing，则可以使用其大小加载延迟加载的集合

看起来它会满足你的要求

Answer 2

Hibernate不必是“要么全部要么无”的解决方案。当符合您的目的时，您可以自由选择直接JDBC

我建议用您选择的DAO编写简单的SELECT COUNT() FROM B查询，然后继续进行

或者你应该问问自己，为什么a的刀总是需要B的大小。我认为DAO应该是无国籍的。为什么不是你的？也许这个设计应该重新考虑一下。从你的问题我看不出来

Answer 3

我认为您可以这样做，因为向您的实体添加这段额外信息可以被视为数据访问的一部分，而不是业务逻辑的一部分

但这只是关于违反设计原则的问题。Paul D'Ambra建议利用hibernate的潜力满足您的需求，这似乎是一个更优雅的解决方案

Answer 4

我的解决方案是我的ADao中的这样一种方法：

 public void loadBs( Collection<A> as ) {
 }

方法中的代码应该将所有外键收集到一个select语句中，然后立即加载所有B，并将它们分发到它们所属的A上

这样，业务/服务代码就可以决定应该为哪一组A所有依赖的B加载，并且可以一次性加载所有依赖的B

编辑：语句“DAO中无逻辑”指“DAO中无业务逻辑”。DAO应该为您的业务/服务层提供对底层数据结构的快速而舒适的访问。但是，如果你开始将业务逻辑转移到那里，你最终会将自己扼杀在一个依赖的网络中

一个很好的例子是一些对象具有“有效时间范围”。时间范围定义为start < end，但将此检查移到DAO中是否是一个好主意

如果您试图加载一个要编辑的对象，例如，它的名称，但时间范围无效，会发生什么情况？如果DAO层拒绝加载这样一个无效的对象，它真的有用吗

或者DAO应该能够加载甚至完全无效的对象，并且所有验证都应该在业务层中进行吗？或者在用户界面层，当用户实际上可以做一些事情，而不是无助地盯着错误消息