打开任何一个后台管理系统，信息系统十有八九跑的管理是MVC。这个词被说烂了，信息系统但真正理解它为什么长这样，管理比背出三个字母代表什么有用得多。信息系统

MVC拆开就是管理Model、View、信息系统Controller。管理Model管数据，信息系统View管展示，管理Controller管调度。信息系统听起来像流水账，管理但关键在“各管各的信息系统”——一个需求改动能只动一层，不用翻遍整个项目找那行该死的管理SQL。

我最早接触MVC是信息系统做一个设备巡检系统。当时用纯PHP写页面，查询逻辑、HTML输出、表单处理全塞在一个文件里。改一个字段名，得同时改五六个地方，漏一处就白屏。后来换成ThinkPHP，第一次把数据库操作抽到Model里，感觉像把缠成一团的耳机线解开了。

Model不是数据库的别名

很多人把Model等同于ORM，写个User::find(1)就觉得MVC用上了。这理解偏了。Model层承载的是业务规则，比如“巡检超时自动升级为紧急工单”这种逻辑，应该放在Model里，而不是Controller里写一堆if-else。Controller只负责接收请求、调用Model、选择View，它不该知道“超时”的具体判定条件。

我见过一个项目，Controller文件超过两千行，里面混杂着SQL拼接、权限判断、邮件发送。这种代码，MVC框架只是给它换了个好看的壳。框架提供的是约束，不是银弹。

View不只是模板文件

View的职责是渲染。但渲染什么、怎么渲染，和前端框架的边界越来越模糊。以前View就是PHP混写HTML，现在很多项目用Vue或React做前端，后端只返回JSON。这时候MVC里的V还存在吗？存在，只是形态变了——它变成了前端组件，Controller变成了API接口层。框架没死，是分层在迁移。

我在一个仓储管理系统里试过前后端分离，后端用Laravel做纯API，前端用Vue。Laravel的Blade模板完全没用上，但Model和Controller的划分依然清晰。这说明MVC的核心不是三个文件夹，而是关注点分离这个原则。

Controller最容易写歪

路由进来先到Controller，所以很多人习惯把所有逻辑往这里堆。请求参数校验、权限检查、业务计算、数据组装，全塞在一个方法里。结果就是Controller成了上帝类，改一处牵动全身。

合理的做法是Controller只做三件事：接收输入、调用服务层或Model、返回响应。参数校验可以交给中间件或FormRequest，权限交给Gate或Policy。Controller越薄，系统越好维护。我现在的习惯是，如果一个Controller方法超过三十行，就会停下来想想哪里放错了。

框架选型没那么重要

ThinkPHP、Laravel、Spring MVC、Django，本质上都在实现同一套分层思想。差别在语法糖、生态和性能。小项目用ThinkPHP上手快，大型企业应用Spring的依赖注入和AOP更成熟。但如果你连MVC为什么这么分都没搞明白，换什么框架都是换个姿势写烂代码。

回到那个巡检系统，后来重构时我把超时判定逻辑从Controller挪到了Model，测试用例从十几个变成三个——因为业务规则集中了，不用再模拟HTTP请求来测一个纯逻辑判断。这大概就是MVC最实在的好处：让该在一起的东西在一起，该分开的东西分开。

(责任编辑：休闲)