在哪里放置这样的业务逻辑？服务vs DAO？

Question

鉴于：

1. Spring MVC - Hibernate。
2. 控制器 - ＆gt;服务 - ＆gt; DAO
3. 现在我有一个方法可以从DB中检索一些东西，而且每次都这样做，必须做另一种方法，比如说“processList”（就像根据一些屏幕参数改变列表中的某些值一样）。

问题：

1. 我把这个“processList”放在哪一层？ （控制器，服务或DAO？以及为什么）

我现在真的需要一些j2ee澄清，我知道MVC在各种语言中是相同的，但我只需要确定:)如果我在.net中这样做，我无疑会将其投入使用。

Answer 1

这实际上取决于processList正在做什么。没有黄金法则。我试图遵循的一些规则是：

1. 切勿在同一图层上的主要对象之间进行调用。
   • ManagementServiceImpl永远不应该致电NotificationServiceImpl。
2. 不要在对象之间建立循环依赖关系。
   • 这与上面的非常类似。
3. 如果您发现自己在多个主要对象上重复某些逻辑，请尝试重新构建代码并将其提取到专门的逻辑类中（这也将改进单元测试）。
   • E.g。 UserUpdateHandler或NotificationDispatcher（这些仍由服务层拥有 - ＆gt;其他任何人都无法调用它们）...
4. 将代码放在逻辑上所属的位置。
   • 不要因为某些班级需要做某事而分心。它可能不是代码的正确位置。
5. 永远不要在需要之前编写完整的通用代码。
   • 这个术语为过早泛化，这是一种类似于过早优化的不良做法。现在保存几行代码可能会导致将来脱发。
6. 始终编写能够变通用的代码。
   • 这与以前不矛盾。这说 - 总是记住概括，但如果不需要，不要费心写作。提前考虑，但不一定要提前行动。
7. 将业务逻辑留给服务层，将数据持久性逻辑留给数据层，将用户交互逻辑留给表示层。
   • 不要尝试解析服务层中的用户输入。这并不属于那里，因为计算电子商店应用程序中的最终价格不属于表示层。

---

processList的一些示例：

• 示例I - 通过Hibernate#initialize获取其他关系
  • 这是服务和DAO层之间真正存在的东西。在较旧的项目中，我们有专门的FetchHandler类（由服务层拥有）。在较新的项目中，我们完全将其留给了DAO。
• 示例II - 浏览列表并将业务验证消息添加到结果中
  • 服务层，毫无疑问
• 示例III - 浏览列表并根据验证错误准备UI消息
  • 表示层

---

旁注：

• MVC与三层架构不同。
• M 模型跨越所有三个图层。表示层包括 V 视图和 C 控制器。