MVC架构中，仅查询场景是否必须定义Controller？

背景 #

根据维基百科中MVC模式的定义，Smalltalk-80语言对MVC的实现规则为：

• View：负责向用户展示信息，与Model对象关联
• Controller：负责处理用户与View的交互，接收输入并转换为Model或View的命令，处理用户输入事件，可验证输入后传递给Model

我在Web应用的MVC架构实践中采用了类似Smalltalk-80的方案：

• Controller接收用户输入，通过业务用例（如Service层）完成领域模型的CUD操作（创建、更新、删除）
• View通过业务用例查询领域模型完成R操作（查询）并返回响应

针对用户输入，我将其分为两类：

• a. 用于更新领域模型的值（如POST表单提交数据）：这类场景必须定义Controller
• b. 仅作为领域模型查询条件的值（如URI中的查询字符串）：我认为这类场景无需定义Controller，可直接将参数传给View，由View通过用例查询模型并构建响应返回给用户

问题 #

1. 当用户输入仅作为领域模型查询条件时，是否必须定义Controller？
2. 如果必须定义，原因是什么？

解答 #

结论：并非必须，但需结合架构一致性与扩展性考量 #

1. 从经典MVC定义角度

Smalltalk-80的MVC中，Controller的核心职责是处理用户交互输入，但并没有强制要求所有输入都必须经过Controller。如果查询参数仅作为View查询模型的条件，且无需额外的输入验证、参数转换或权限校验，直接由View接收参数并处理查询是符合Smalltalk-80中View与Model关联的设计逻辑的。

2. 建议定义Controller的场景

如果存在以下情况，更适合通过Controller处理查询输入：

• 输入校验与转换：查询参数需要格式校验（如日期格式、数值范围）、类型转换（如字符串转枚举），或者需要对参数进行预处理（如多条件组合、默认值填充），Controller可以统一承担这类职责，避免View逻辑臃肿
• 权限控制：查询操作需要验证用户是否具备对应数据的访问权限，Controller作为请求入口可以统一拦截并校验权限，避免在View中散列权限逻辑
• 架构一致性：团队约定所有请求都必须经过Controller层统一处理，保持代码结构的一致性，降低新人维护成本
• 扩展性需求：未来可能需要在查询流程中增加日志埋点、请求限流、缓存控制等横切逻辑，Controller作为统一入口更便于扩展，无需修改View层代码

内容的提问来源于stack exchange，提问作者user9455607