鉴于:
Spring MVC - 休眠。 Controller -> 服务 -> DAO 现在我有一个方法可以从数据库中检索一些东西，并且每次都这样做，必须执行另一种方法，比如“processList”(就像只是根据某些屏幕参数更改列表中的某些值)。 题:
我把这个“processList”放在哪一层？ ( Controller 、服务或 DAO？以及为什么)我现在真的需要一些 j2ee 说明，我知道 MVC 跨语言是相同的，但我只需要确定:) 如果我在 .net 中执行此操作，我无疑会将其投入使用。
这真的取决于什么processList正在做。没有黄金法则。我尝试遵循的一些规则是:
切勿在同一层上的主要对象之间进行调用。
ManagementServiceImpl永远不要打电话 NotificationServiceImpl . 不要在对象之间建立循环依赖。
这与上面的非常相似。 如果您发现自己在多个主要对象中重复了某些逻辑，请尝试重构代码并将其提取到专门的逻辑类中 (这也将改进单元测试)。
例如。 UserUpdateHandler或 NotificationDispatcher (这些仍然归服务层所有 -> 不允许其他人调用它们)... 将代码放在逻辑上属于它的地方。
不要因为某些类(class)需要做某事而分心。它可能不是代码的正确位置。 永远不要在需要之前编写完全通用的代码。
这称为过早泛化，这是一种类似于过早优化的不良做法。现在保存几行代码可能会导致您在 future 脱发。 始终编写能够泛化的代码。
这与前面的并不矛盾。这就是说 - 始终牢记泛化，但如果不需要，请不要写。提前思考，但不一定提前行动。 业务逻辑留给服务层，数据持久化逻辑留给数据层，用户交互逻辑留给表现层。
不要尝试在服务层解析用户输入。这不属于那里，因为在电子商店应用程序中计算最终价格不属于表示层。 processList 的一些示例:
示例一 - 通过 Hibernate#initialize 获取其他关系
这是真正介于服务层和 DAO 层之间的东西。在旧项目上，我们有专门的 FetchHandler类(由服务层拥有)。在较新的项目中，我们将这完全留给 DAO。 示例二 - 浏览列表并添加 业务验证结果的消息
服务层，毫无疑问 示例三 - 浏览列表并根据验证错误准备 UI 消息
表示层 边注:
MVC 与三层架构不同。 男 模型跨越所有三层。表示层包括 V View 和 C Controller 。