ASP MVC：别神话它，也别急着抛弃它

我见过太多团队把ASP.NET MVC当成银弹，也见过更多团队在Web Forms的泥潭里挣扎后，把MVC当成了救世主。可真相是——MVC只是把控制权还给了开发者，代价是你得自己扛起所有细节。

2012年我接了个政府项目，用的是Web Forms。那会儿页面生命周期像条锁链，ViewState能把一个表格撑到200KB。后来换到MVC，第一周团队集体懵了：没有服务器控件，没有事件模型，连个简单的下拉框联动都得自己写JavaScript。但两周后，有人开始享受这种“裸奔”的爽快感——URL干净得像刚擦过的玻璃，HTML输出就是纯粹的HTML，不再裹着那层又臭又长的__VIEWSTATE。

MVC的核心价值从来不是“分离关注点”这种教科书说法。它真正改变的是你思考请求的方式。在Web Forms里，你问“这个按钮点击后发生什么”；在MVC里，你问“这个URL应该返回什么”。这不仅是技术切换，是思维范式转换。路由表就是你的应用地图，每一个Controller Action都是地图上的坐标点。

但别被那些Demo骗了。真实项目里，Controller很快就会臃肿起来。我见过一个Controller写了3000行，里面塞满了各种业务逻辑。这不是MVC的错，是人性的懒惰——既然Action方法这么方便，那就全往里堆呗。这时候你得自己引入Service层，或者用Mediator模式把逻辑拆出去。框架不给答案，它只给画布。

Razor视图引擎是我最喜欢的那部分。它比Web Forms的模板干净太多，但比纯HTML又多了点温度。@if、@foreach直接在HTML里流动，像给静态页面注入了微弱的生命体征。不过有个坑——新手容易在视图里写复杂C#代码，结果页面逻辑比Controller还重。记住，视图只负责展示，任何需要思考的判断都该提前处理好。

性能方面，MVC默认比Web Forms轻量，因为少了ViewState和页面生命周期那套开销。但别高兴太早，如果你用了大量HtmlHelper扩展或者频繁访问ViewBag，照样会慢。我做过一次优化，把某个页面的ViewBag换成强类型模型，响应时间直接降了40%。强类型不是矫情，是给运行时减负。

现在.NET Core都出到8了，ASP.NET MVC这个老名字已经融进了更大的框架体系里。但它的核心思想——路由映射、Action返回结果、模型绑定——依然在。我甚至觉得，MVC那套“约定优于配置”的理念，比后来的Minimal API更值得深思。Minimal API太快了，快到容易忽略架构边界。MVC的Controller像一道门槛，逼着你思考每个请求的归属。

如果你还在用Web Forms，别急着迁移。MVC不会自动让你的代码变好，它只是把选择权交还给你。我见过用MVC写出比Web Forms更烂代码的团队，也见过用Web Forms写出清晰架构的团队——工具只是骨架，肌肉和神经都在人身上。

最后说句实在话：如果你要快速搭建内部工具，MVC可能有点重。但如果你要做一个长期维护、路由清晰、前端可分离的Web应用，MVC依然是个靠谱的老朋友。它不性感，不新潮，但它实在——就像一把用顺手的旧扳手，你总会在某个需要精准拧螺丝的下午，想起它来。