为什么你的 TP5.1 代码难以维护？MVC 分层重构最佳实践【规范】

说白了，如果TP5.1的Controller层直接跟Db::table()玩上了，验证逻辑到处乱塞，业务判断随手一写，那这控制器早就不是控制器了，而是个“缝合怪调度中心”。这样的代码，维护成本会随着迭代翻着跟头往上涨——不是“难维护”，是“根本不敢动”。

一旦在Controller里看到Db::table()，直接喊停就好

TP5.1的Db类确实是数据访问的快捷入口，但它不应该出现在Controller里。一旦看到类似这样的代码：

$user = Db::table('user')->where('id', $id)->find();

这就说明职责已经泄漏了：Controller揽下了数据获取、基础过滤、状态组装三件事。后续要加个字段映射、改个关联查询、补个缓存逻辑，都得改Controller，测试也得跟着重写。

• 正确的路径是：Controller → Service → Repository（或Model）
• Service层负责组合逻辑（比如“查用户 + 查其最近3条订单 + 拼装头像URL”），Repository负责单表CRUD
• TP5.1里可以建app\common\repository\UserRepository，把Db::table('user')封装进它的findById()方法里
• Controller只保留$this->userService->getProfile($id)这种语义清晰的调用

validate()确实是好工具，但千万别把它当成万能胶，随手往request()上一贴就完事

TP5.1的validate()很方便，但如果把它当成补丁，打在request()->param()后面，很快就会失控。常见的症状包括：

• 同一个字段在多个方法里重复定义规则（比如'email' => 'require|email'出现在5个Controller方法里）
• 规则里塞了业务逻辑（'password' => 'require|checkOldPassword:uid'，把密码校验耦合进验证器）
• 验证失败后手动拼['code'=>400, 'msg'=>'xxx']，和统一响应结构冲突

建议的做法是：

• 每个业务动作建独立的验证器类，比如app\validate\User\UpdateProfileValidate
• 验证器只做字段格式、长度、必填等基础检查；业务规则（比如“新邮箱不能与旧邮箱相同”）移入Service层
• 在基类Controller中统一拦截ValidateException，转为Result::fail(400, $e->getMessage())

Service层别变成Controller的镜像副本

很多重构其实就是把Controller里的代码剪切粘贴到Service，方法名照抄（index()、save()、delete()），参数一模一样。这根本没解决问题——只是把“胖Controller”换成了“胖Service”。

真正有效的Service接口设计，应该满足这些条件：

• 方法名体现业务意图，而不是HTTP动词：createUserWithInviteCode()比save()明确得多
• 参数尽量聚合：用UserCreateDTO对象传参，而不是一堆$name, $email, $phone, $source
• 返回值类型稳定：不返回array或bool，统一用Result包装，即使成功也带data字段（空数组或null）
• 事务边界清晰：一个Service方法对应一个完整业务用例，跨表操作必须包裹Db::transaction()

View层里嵌PHP逻辑，是重构时最容易被忽略的腐化点

TP5.1的模板引擎支持{:function()}和{php}...{/php}，但这类用法在重构时最容易成为盲区。比如：

{volist name="list" id="vo"}{:date('Y-m-d', $vo.create_time)}{if $vo.status == 1}已启用{else}已禁用{/if}{/volist}

这类逻辑本该由Controller或Service提前处理好。比如：

• 把create_time格式化成字符串字段塞进$vo，模板只做展示
• 状态码转文字映射放到Service层（statusText($vo.status)），Controller组装进data返回
• 模板里只留纯变量插值：{$vo.formatted_create_time} {$vo.status_text}

否则，前端改个日期格式，或者运营要加个“试用期状态”标签，都得翻模板、找PHP片段、改逻辑、再测——这不是前端工作，是后端调试。

最难重构的，从来不是哪行代码写错了，而是那些“跑得通、看起来没问题、但谁都不敢删”的胶水逻辑。它们潜藏在验证器里、混在模板中、躺在Service方法命名背后。重构TP5.1项目，关键不是换框架，而是让每一层只说自己的语言：Controller说“我要什么”，Service说“这事怎么干”，Repository说“数据在哪”，View说“我怎么画”。