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

Question

鉴于:

1. Spring MVC - Hibernate.
2. 控制器 - >服务 - > DAO
3. 现在我有一个从DB中检索某些东西的方法,并且每次都这样做,必须做另一种方法,比如说"processList"(就像根据某些屏幕参数改变列表中的某些值一样).

题:

1. 我把这个"processList"放在哪一层？(控制器,服务或DAO？为什么)

我现在真的需要一些j2ee澄清,我知道MVC在各种语言中是相同的,但我只需要确定:)如果我在.net中这样做我无疑会把它放在服务中.

Answer 1

这实际上取决于究竟processList做了什么.没有黄金法则.我试图遵循的一些规则是:

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

一些例子processList:

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

边注:

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