用于重构被滥用的 MVC 控制器类的 Java 模式

Posted 2023-03-31

【中文标题】用于重构被滥用的 MVC 控制器类的 Java 模式

【英文标题】：Java pattern for refactoring abused MVC controller class

【发布时间】：2021-01-13 17:52:48

【问题描述】：

所以我继承了这个可能有 10 年历史的意大利面条后端服务代码库，它是用 Java 和 maven 编写的。 原作者在 RequestController 类中放了很多东西，它的功能类似于

processPostRequestV1
processPostRequestV2
....
processPostRequestV6

和

getRequestV1
getRequestV2
...
getRequestV6

以及这一类中的所有实用功能。

它们都对同一个数据库进行读写（感谢上帝），但这个类有近 20 个依赖 bean 和 3000 行代码。

我想知道，重构这种代码的最佳模式是什么，它似乎是一个编排层，但是应该使用什么模式来管理它的版本？ （有些版本甚至没有意义，例如旧版本的代码与新版本共享代码，使用新的依赖项等，但这是另一回事）

在 MVC 模式中，控制器应该从模型/业务层收集/更新数据，这看起来与这个 RequestController 类正在做的完全一样，我在这里缺少什么？

【问题讨论】：

你需要重构它吗？如果你只是想，但你没有诀窍，那么最好不要碰它。

不要重构它，除非它有错误或者你想添加新功能

我的意见是，如果您有足够的时间来完成其他任务，那么您应该重构代码，如果您的职责是将该应用程序再维护 10 年。我要做的第一件事就是尝试找到一种方法来为它编写测试。即使这意味着启动整个应用程序并编写脚本向其发送请求并验证响应（端到端测试）。我知道测试遗留代码可能具有挑战性，但测试将作为您的安全网，这样您就不会在重构时引入错误。

【参考方案1】：

首先...您有针对该课程的测试吗？你信任的测试？如果不是，请不要重构。先写测试。

因为重构意味着

改变代码的结构而不改变它的行为

如果您有测试，我会创建一个新结构并更改 RequestController 类的方法以委托给新结构。

也许新结构类似于clean architecture、BCE（边界控制器实体）或六边形架构。

在干净架构的情况下。 RequestController 将通过用例的输入边界传递请求模型，并向用例传递一个输出边界，请求控制器将适应该输出边界以返回结果。

看看https://softwareengineering.stackexchange.com/questions/388578/clean-architecture-is-the-input-boundary-necessary