在道边有逻辑不是一个好习惯吗？

Question

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

在服务层中，我执行延迟加载时无法执行此操作。我必须在dao侧设置瞬态值。但我听说dao方没有逻辑。

我该怎么办？任何解释都表示赞赏。

Answer 1

如果你看Hibernate count collection size without initializing，你可以加载延迟加载的集合

这似乎符合您的要求......

Answer 2

Hibernate不一定是“全有或全无”的解决方案。您可以根据自己的需要自由选择直接JDBC。

我建议在您选择的DAO中编写简单的SELECT COUNT() FROM B查询并继续处理。

或许您应该问问自己为什么A的DAO一直需要B的大小。我认为DAO应该是无国籍的。为什么不是你的？也许应该重新考虑设计。我无法从你的问题中说出来。

Answer 3

我的解决方案将是ADao：

中的一种方法

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

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

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

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

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

如果您尝试加载要编辑的对象，比如它的名称但时间范围无效，会发生什么？如果DAO层拒绝加载这样的无效对象，它会非常有用吗？

或者DAO是否应该能够加载甚至完全无效的对象，并且所有验证都应该在业务层中进行？或者在UI层中，当用户可以实际执行某些操作而不是无助地盯着错误消息时？

Answer 4

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

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