ASP.NET MVC架构设计哲学与政企系统可维护性实践

1. 项目概述：这不是一篇技术文档，而是一次十年老程序员的深夜复盘

“ASP.NET MVC随想”——光看这个标题，你可能以为是某篇泛泛而谈的怀旧笔记，或是刚学完MVC基础的初学者随手写的读书感想。但如果你在2012–2018年间深度参与过国内中大型企业级Web系统建设，尤其是金融、政务、制造类后台平台开发，那这五个字背后藏着的，是一整套被时间反复锤炼过的工程方法论：如何在强约束环境下，用有限的技术杠杆撬动高可靠、可审计、易交接的业务系统。我带过7个交付团队，亲手重构过11个遗留ASP.NET WebForms项目，其中9个最终落地为标准MVC架构；不是因为MVC多先进，而是它把“谁改了哪行逻辑”“权限校验落在哪一层”“日志怎么打才不漏关键上下文”这些运维和审计最关心的问题，硬生生编进了框架契约里。它不解决“能不能做”，而是死磕“能不能管、能不能查、能不能换人接着干”。今天这篇内容，不讲RouteConfig怎么配，不贴ActionResult返回示例，也不对比MVC和Core孰优孰劣——我要带你回到那个没有Docker、没有CI/CD流水线、连NuGet都常超时的年代，看清MVC真正不可替代的价值锚点： 它用约定代替配置，用分层切口换来了系统可维护性的下限保障 。适合三类人细读：正在维护老系统的后端工程师（别急着喊重构）、带团队做政企交付的技术负责人（你需要向甲方解释清楚“为什么必须用Area隔离模块”）、以及想真正理解“框架设计哲学”而非仅会调API的进阶开发者。下面所有分析，全部来自真实交付现场的血泪记录。

2. 架构设计底层逻辑：为什么是MVC，而不是WebForms或纯Web API？

2.1 WebForms的“拖控件幻觉”如何成为交付灾难的温床

很多刚从学校出来的开发者，第一次接触ASP.NET时会被WebForms的“双击事件自动生成代码”惊艳到——TextBox加个OnTextChanged，后台立刻跳出protected void TextBox1_TextChanged(...)，连HTTP请求周期都不用想。但这种便利性在真实项目中恰恰是毒药。我接手过一个省级社保申报系统，原团队用WebForms三年，页面.aspx文件平均2300行，其中60%是ViewState序列化后的base64字符串。当需要排查“为什么修改参保人数后，页面刷新时自动清空了缴费基数”这类问题时，你得先解码ViewState，再比对前后两次__EVENTVALIDATION的哈希差异，最后在Page_Load里翻出那段被注释掉的if (!IsPostBack) {...}——而这段代码，写在.cs文件第1872行，旁边还留着“//2015年张工加，说是为了兼容IE6”的注释。WebForms把HTTP无状态本质彻底掩盖了，结果就是： 业务逻辑和UI渲染耦合在同一个生命周期里，调试=猜谜，交接=考古 。更致命的是，它的事件模型天然排斥自动化测试——你根本没法Mock一个“点击按钮触发服务端回发”的行为，因为整个回发链路依赖Page对象的完整实例化过程。我们做过统计：同样功能的模块，WebForms版本的单元测试覆盖率平均只有12%，而MVC版本稳定在68%以上。这不是工具问题，是架构基因决定的。

2.2 为什么没直接上Web API？——政企场景下的“协议合规性”铁律

有人会问：既然要解耦，为什么不一步到位用Web API + 前端SPA？2014年我们真这么干过，在某市公积金中心项目里，前端用AngularJS，后端全走RESTful API。结果上线前卡在等保测评环节：测评报告明确指出“系统未实现服务端页面渲染，无法满足《GB/T 22239-2019》中‘应用系统应具备服务端输入验证能力’的要求”。甲方信息科主任拿着红头文件拍桌子：“你们前端JavaScript校验算什么？浏览器F12删掉验证代码就能绕过！必须在服务端生成HTML时就把非法字符过滤掉！” 这就是现实——在政务、金融等强监管领域，“能被用户看到的HTML，必须由服务端完全可控地生成”是一条红线。MVC的View引擎（Razor）完美契合这点：@model声明类型安全、@Html.TextBoxFor()自动转义XSS、@{ Layout = null; }可精确控制输出结构。而Web API只管JSON，HTML渲染甩给前端，等于把安全责任推给了不可信的客户端环境。后来我们调整方案：核心业务流（如贷款审批、合同签署）强制使用MVC View渲染，仅将报表导出、大文件上传等非关键路径拆成Web API。这个折中方案通过了等保三级认证，也成了我们后续所有政企项目的默认架构基线。

2.3 MVC的“三层刚性切口”如何成为团队协作的契约

MVC最被低估的价值，是它用文件夹结构+命名规范，强行划出了三道不可逾越的职责边界：

• Controller层 ：只做三件事——接收请求参数、调用Service、决定返回哪个View（或Redirect）。它不能碰数据库连接字符串，不能写SQL，甚至不能new一个实体类（必须依赖IoC容器注入）；
• Model层 ：严格限定为数据契约（DTO）和领域实体（Entity），禁止包含任何业务逻辑。我们曾明文规定：Model类里出现if/for/switch关键字，Code Review直接打回；
• View层 ：纯展示逻辑，只允许@model、@Html.xxx、@Url.Action()三类语法，禁止调用Service、禁止访问Session（必须通过ViewBag传递且需在Controller中显式赋值）。

这套规则看似教条，却解决了团队协作中最痛的痛点。举个真实案例：某银行信贷系统有5个子模块（客户管理、额度测算、合同生成、放款审核、贷后跟踪），每个模块由不同小组开发。如果没有MVC的分层约束，A组写的客户管理Controller里可能顺手调用了B组的额度测算Service，而B组重构Service接口时忘了通知A组，结果上线后“新增客户”功能直接报500错误。但有了MVC契约，所有跨模块调用必须通过定义清晰的Interface（如ICreditLimitService），且Controller只能通过构造函数注入——这意味着： 任何接口变更都会在编译期暴露，而不是在凌晨三点的生产环境报警 。我们团队因此把Code Review重点从“代码有没有bug”转向了“Controller有没有偷偷访问不该访问的层”，效率提升非常明显。

3. 核心机制深度拆解：路由、模型绑定与视图引擎的协同设计

3.1 RouteConfig不是URL美化工具，而是权限治理的第一道闸门

很多人把RouteConfig.cs当成单纯配置URL路径的文件，比如把/Products/Details/5改成/Product/5。但我们在实际项目中，把它用作 权限策略的集中注册点 。看这个真实配置：

routes.MapRoute(
    name: "AdminArea",
    url: "admin/{controller}/{action}/{id}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
    namespaces: new[] { "MyApp.Areas.Admin.Controllers" }
).DataTokens["area"] = "Admin";

routes.MapRoute(
    name: "FinanceArea",
    url: "finance/{controller}/{action}/{id}",
    defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional },
    namespaces: new[] { "MyApp.Areas.Finance.Controllers" }
).DataTokens["area"] = "Finance";

关键不在url模板，而在DataTokens["area"] = "Admin"这行。它让框架在路由匹配后，自动把当前请求标记为“Admin区域”。然后我们在全局ActionFilter里做统一拦截：

public class AreaPermissionFilter : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var area = filterContext.RouteData.DataTokens["area"] as string;
        if (string.IsNullOrEmpty(area)) return;

        var user = HttpContext.Current.User as CustomPrincipal;
        if (!user.HasPermission(area)) // 调用统一权限服务
        {
            filterContext.Result = new HttpStatusCodeResult(HttpStatusCode.Forbidden);
        }
    }
}

这样做的好处是： 权限控制点从分散在每个Controller的[Authorize]特性，收束到单一配置文件+全局Filter 。当甲方要求“财务模块所有接口必须增加二次密码验证”时，我们只需在AreaPermissionFilter里加几行代码，而不用去翻遍FinanceArea下27个Controller的43个Action。更妙的是，路由配置本身成了权限文档——运维同事直接看RouteConfig就知道系统有几个业务域，每个域的URL前缀是什么，比翻需求文档快十倍。

3.2 模型绑定（Model Binding）的隐式安全机制：从字符串到实体的可信转化链

MVC的ModelState.IsValid检查常被新手当作“表单验证是否为空”的快捷方式，但它真正的价值在于构建了一条 从原始HTTP请求到强类型实体的安全转化链 。以一个典型的贷款申请表单为例：

<!-- View -->
@using (Html.BeginForm("Apply", "Loan", FormMethod.Post))
{
    @Html.TextBoxFor(m => m.Amount, new { @class = "form-control" })
    @Html.TextBoxFor(m => m.TermMonths, new { @class = "form-control" })
    <button type="submit">提交申请</button>
}

对应的Model：

public class LoanApplicationModel
{
    [Range(1000, 5000000, ErrorMessage = "贷款金额必须在1000-5000000元之间")]
    public decimal Amount { get; set; }

    [Range(1, 360, ErrorMessage = "期限必须在1-360个月之间")]
    public int TermMonths { get; set; }
}

当用户提交Amount=10000000时，MVC的DefaultModelBinder会执行三步操作：

1. 类型转换 ：尝试把字符串"10000000"转为decimal，失败则ModelState.AddModelError("Amount", "格式错误")；
2. 验证执行 ：调用RangeAttribute的IsValid()方法，传入已转换的decimal值，返回false则添加对应错误消息；
3. 绑定抑制 ：如果ModelState.IsValid为false，Controller的LoanApplicationModel参数将保持null（或默认值），绝不会让非法值进入业务逻辑层。

这个过程的关键在于： 所有验证都在模型绑定阶段完成，且验证规则与模型定义强绑定 。对比WebForms里常见的“TextBox.Text.Trim() != string.Empty”式校验，MVC的绑定机制天然防住了：

• 用户F12修改HTML的max属性绕过前端限制；
• Postman直接发送Amount=abc的恶意请求；
• 甚至服务器时区导致DateTime.Parse失败的边界情况（通过自定义IModelBinder可处理）。

我们曾用Fiddler向生产环境发送10万次畸形请求压测，所有非法输入均被ModelState拦截，零次进入Service层——这省去了在每个Service方法开头写if (amount <= 0 || amount > 5000000)的重复劳动。

3.3 Razor视图引擎的“编译时安全”：为什么.cshtml比.aspx更抗风险

Razor的@符号语法常被吐槽学习成本高，但它带来的编译时检查能力，是WebForms望尘莫及的。看这个对比：

// WebForms .aspx 文件（运行时才报错）
<%# Eval("CustomerName") %> <!-- 如果CustomerName不存在，页面白屏 -->
<% if (Session["UserLevel"] == "Admin") { %> 
    <a href="/admin/delete">删除</a> <!-- Session可能为null，运行时报NullReferenceException -->
<% } %>

// Razor .cshtml 文件（编译期就报错）
@model LoanApplicationModel
@Html.TextBoxFor(m => m.Amount) <!-- 如果Model没有Amount属性，VS直接标红 -->
@if (User.IsInRole("Admin")) // User对象由框架保证不为null
{
    <a href="@Url.Action("Delete", "Admin")">删除</a>
}

Razor的核心优势在于： 所有@表达式都在Visual Studio编译时解析 。当你在View里写@Model.CustomerName，IDE会实时检查LoanApplicationModel类是否存在CustomerName属性；写@Url.Action("NonExist", "Controller")，它会提示“找不到名为NonExist的Action”。这种编译时安全，让团队新人也能快速发现低级错误——不需要等QA提bug，不需要看F12控制台报错。更关键的是，它倒逼开发者遵守契约：View必须声明@model，Controller必须返回正确类型的ViewResult。我们团队曾统计，采用Razor后，因“View引用了不存在的Model属性”导致的线上故障下降了92%。这不是玄学，是编译器给你兜的底。

4. 实战工程化落地：从零搭建可交付的MVC项目骨架

4.1 项目分层结构设计：为什么Controllers文件夹里永远不放业务代码

一个可交付的MVC项目，绝不能是Visual Studio默认模板的简单复制。我们强制采用五层物理结构（按Solution Explorer顺序）：

MyApp.Web          // MVC项目（仅含Controllers/Views/Content/Scripts）
MyApp.Core         // 领域模型、领域服务接口（无具体实现）
MyApp.Infrastructure // EF DbContext、仓储实现、第三方SDK封装
MyApp.Application  // 应用服务（协调领域服务，处理用例）
MyApp.Common       // 工具类、扩展方法、全局异常处理

重点说MyApp.Application层。这里存放所有Controller直接调用的服务，例如：

// MyApp.Application/Services/LoanApplicationService.cs
public class LoanApplicationService : ILoanApplicationService
{
    private readonly ILoanRepository _loanRepo;
    private readonly ICustomerService _customerService; // 依赖领域服务接口
    
    public LoanApplicationService(ILoanRepository loanRepo, ICustomerService customerService)
    {
        _loanRepo = loanRepo;
        _customerService = customerService;
    }

    public async Task<bool> SubmitApplicationAsync(LoanApplicationModel model)
    {
        // 1. 调用领域服务校验客户资质
        var customer = await _customerService.GetByMobileAsync(model.Mobile);
        if (customer == null) throw new BusinessException("客户不存在");

        // 2. 执行领域规则（如：同一客户30天内最多申请2笔）
        if (await _loanRepo.CountByCustomerIdAsync(customer.Id) >= 2)
            throw new BusinessException("超出申请次数限制");

        // 3. 创建领域实体并保存
        var loan = new LoanEntity { ... };
        await _loanRepo.AddAsync(loan);
        return true;
    }
}

Controller只负责胶水作用：

// MyApp.Web/Controllers/LoanController.cs
public class LoanController : Controller
{
    private readonly ILoanApplicationService _loanService;

    public LoanController(ILoanApplicationService loanService)
    {
        _loanService = loanService;
    }

    [HttpPost]
    public async Task<ActionResult> Apply(LoanApplicationModel model)
    {
        try
        {
            await _loanService.SubmitApplicationAsync(model);
            return RedirectToAction("Success");
        }
        catch (BusinessException ex)
        {
            ModelState.AddModelError("", ex.Message);
            return View(model);
        }
    }
}

这种设计的好处是： Controller代码量稳定在50行以内，所有业务逻辑可独立单元测试，且能被其他接入方式（如Web API、Windows Service）复用 。我们曾用同一套Application层代码，同时支撑了MVC前台、微信公众号H5、以及银行内部OA系统的嵌入式iframe——因为它们都调用ILoanApplicationService，而不用关心上层是View还是JSON。

4.2 全局异常处理：用HandleErrorAttribute打造用户友好的错误闭环

默认的HandleErrorAttribute只处理500错误，且返回静态Error.cshtml。在真实项目中，我们必须区分三类异常并差异化处理：

实现方案是在Global.asax.cs中注册全局Filter：

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new HandleErrorAttribute());
    filters.Add(new GlobalExceptionFilter()); // 自定义Filter
}

public class GlobalExceptionFilter : IExceptionFilter
{
    public void OnException(ExceptionContext filterContext)
    {
        if (filterContext.ExceptionHandled) return;

        var exception = filterContext.Exception;
        var result = GetActionResult(exception);

        filterContext.Result = result;
        filterContext.ExceptionHandled = true;
        LogException(exception); // 记入ELK日志系统
    }

    private ActionResult GetActionResult(Exception exception)
    {
        if (exception is BusinessException busEx)
        {
            return new JsonResult { Data = new { success = false, message = busEx.Message } };
        }
        if (exception is ValidationException valEx)
        {
            return new HttpStatusCodeResult(HttpStatusCode.BadRequest, valEx.Message);
        }
        // 其他异常返回500
        return new ViewResult { ViewName = "Error500" };
    }
}

这个设计让前端开发变得极其简单：所有AJAX请求统一处理response.status，无需每个接口单独写error回调。更重要的是， 它把异常分类从“开发人员的调试习惯”升级为“系统级契约” ——测试同学知道BusinessException必须有用户提示，运维知道SystemException必须查日志，产品知道ValidationException对应的是前端交互缺陷。

4.3 日志与审计：在Controller基类中埋入不可绕过的追踪点

政企系统最怕“谁在什么时候改了什么数据”。我们通过Controller基类强制注入审计日志：

public abstract class BaseController : Controller
{
    protected readonly IAuditLogger _auditLogger;

    protected BaseController(IAuditLogger auditLogger)
    {
        _auditLogger = auditLogger;
    }

    protected override void Initialize(RequestContext requestContext)
    {
        base.Initialize(requestContext);
        _auditLogger.SetContext(User.Identity.Name, Request.UserHostAddress, 
                               Request.Url?.ToString() ?? "");
    }
}

// 在具体Controller中
public class LoanController : BaseController
{
    public LoanController(IAuditLogger auditLogger) : base(auditLogger) { }

    [HttpPost]
    public ActionResult Approve(int id)
    {
        var loan = _loanRepo.GetById(id);
        _auditLogger.Log($"审批贷款{id}，原状态{loan.Status} -> 新状态Approved"); // 关键操作必记
        loan.Status = "Approved";
        _loanRepo.Update(loan);
        return Json(new { success = true });
    }
}

IAuditLogger实现类会将日志写入独立数据库表，并同步推送至公司统一日志平台。关键设计点在于：

• SetContext()在Initialize阶段调用 ，确保每次请求都有完整上下文（用户、IP、URL）；
• Log()方法接受自由文本 ，避免为每个操作定义枚举，降低开发成本；
• 日志表结构包含RequestId字段 ，可关联APM系统（如AppDynamics）的完整调用链。

这套机制让我们在某次银保监检查中，5分钟内就导出了“某客户所有贷款操作记录”，而隔壁团队还在手动拼接IIS日志和数据库binlog。

5. 真实踩坑记录：那些文档里永远不会写的MVC生存指南

5.1 ViewBag/ViewData/TempData的“三界之争”：何时该用谁？

新手常困惑：三个传值机制到底有什么区别？我们的经验是用一张表终结争论：

最经典的翻车现场：某同事在LoginController里写：

TempData["Success"] = "登录成功";
return RedirectToAction("Index", "Home");

然后在Home/Index.cshtml里：

@if (TempData["Success"] != null) 
{
    <div class="alert">@TempData["Success"]</div>
}
@if (TempData["Success"] != null) // 第二次读取！永远为false
{
    <script>alert('欢迎回来');</script>
}

结果用户永远看不到alert。解决方案是用TempData.Peek()或TempData.Keep()：

@if (TempData.Peek("Success") != null) 
{
    <div class="alert">@TempData["Success"]</div>
    <script>alert('欢迎回来');</script>
}

提示：TempData底层依赖Session，所以必须确保SessionStateMode为InProc或StateServer。我们曾在线上环境因web.config里误配sessionState mode="Off"，导致所有重定向提示消息丢失，排查了两天才发现是配置问题。

5.2 Partial View的“缓存幻觉”：为什么@Html.Partial()比@{ Html.RenderPartial(); }更危险？

Partial View常用于复用导航栏、分页组件。但两种调用方式有本质区别：

<!-- 方式1：@Html.Partial() -->
@Html.Partial("_Header") // 返回MvcHtmlString，可被ViewBag赋值

<!-- 方式2：@{ Html.RenderPartial(); } -->
@{ Html.RenderPartial("_Header"); } // 直接写入Response.Output，无返回值

危险在于：@Html.Partial()会创建新的ViewContext，而RenderPartial()复用当前ViewContext。这意味着——

• 如果你在_Header.cshtml里写了@ViewBag.Title = "Header"，用@Html.Partial()会导致主View的ViewBag.Title被覆盖；
• 但用RenderPartial()则不会，因为它不新建ViewContext。

我们曾因此出现诡异Bug：用户访问/Products/List时，页面顶部显示“产品列表”，但点击分页链接后，顶部变成“首页”——因为分页组件_Pagination.cshtml里有一行@ViewBag.Title = "分页"，而它被@Html.Partial()调用，污染了主View的ViewBag。解决方案很简单： 所有Partial View禁用ViewBag赋值，改用ViewData["Title"]或ViewModel属性传递 。或者更彻底：用@Html.Action()替代，让Partial View拥有独立Controller，彻底隔离上下文。

5.3 Area路由冲突：当两个Area定义相同Controller名时的灾难性后果

这是政企项目高频雷区。假设你有AdminArea和FinanceArea，都定义了UserController：

// AdminArea/Controllers/UserController.cs
namespace MyApp.Areas.Admin.Controllers
{
    public class UserController : Controller { ... }
}

// FinanceArea/Controllers/UserController.cs  
namespace MyApp.Areas.Finance.Controllers
{
    public class UserController : Controller { ... }
}

问题来了：当访问/admin/user/edit/1时，MVC默认按命名空间搜索，但若FinanceArea的UserController编译顺序靠前，请求可能被错误路由到FinanceArea的UserController！原因在于： MVC的AreaRegistration.RegisterAllAreas()按程序集加载顺序注册，而非按Area名称字母序 。

解决方案有二：

1. 显式指定命名空间 （推荐）：在AreaRegistration.cs中：

context.MapRoute(
    "Admin_default",
    "admin/{controller}/{action}/{id}",
    new { action = "Index", id = UrlParameter.Optional },
    new[] { "MyApp.Areas.Admin.Controllers" } // 强制限定命名空间
);

2. 用路由约束排除干扰 ：

context.MapRoute(
    "Admin_default",
    "admin/{controller}/{action}/{id}",
    new { action = "Index", id = UrlParameter.Optional },
    new { controller = "^(?!User$).*" } // 排除User控制器（由FinanceArea专用）
);

注意：正则约束中的^和$必须加上，否则"User"会匹配"UserController"。我们吃过亏——某次发布后，AdminArea的用户管理页面突然404，查了三小时才发现是FinanceArea的UserController被优先匹配了。

5.4 发布部署的“DLL地狱”：GAC与Bin目录的战争

MVC项目发布到IIS时，最头疼的是DLL版本冲突。比如：

• 你的项目引用Newtonsoft.Json 12.0.3；
• 某个老系统装在GAC里的却是9.0.1；
• IIS加载时优先从GAC找，结果运行时报“Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0'”。

解决方案不是卸载GAC旧版（可能影响其他系统），而是强制走本地Bin目录：

<!-- web.config 的 <configuration> 节点下 -->
<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="Newtonsoft.Json" 
                        publicKeyToken="30ad4fe6b2a6aeed" 
                        culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-12.0.3.0" 
                       newVersion="12.0.3.0" />
      <codeBase version="12.0.3.0" 
                href="bin\Newtonsoft.Json.dll" />
    </dependentAssembly>
  </assemblyBinding>
</runtime>

关键在 <codeBase> 节点：它告诉CLR“这个版本的DLL必须从bin目录加载，不准去GAC找”。我们所有项目发布包都包含此配置，且用PowerShell脚本自动注入——因为手工改web.config在紧急发布时极易遗漏。

6. 经验总结：MVC教会我的三件反直觉的事

我在2018年最后一次用MVC交付项目（某省税务局发票查验系统），之后团队全面转向.NET Core。但回头看，MVC留给我的思维遗产远比代码更有价值。第一件反直觉的事： 框架的“不自由”才是最大生产力 。当年被强制要求Controller不能写SQL、View不能调Service时，我满腹牢骚；直到接手一个WebForms遗留系统，看着满屏ViewState和Page_Load里嵌套七层if-else，才明白MVC用分层枷锁换来的，是新人三天内就能读懂核心流程的确定性。第二件： 编译时检查比单元测试更能守住底线 。Razor的@model强类型、RouteConfig的命名空间约束，这些看似繁琐的约定，让90%的低级错误在敲下Ctrl+S时就被捕获，而不是在Code Review时被揪出来。第三件也是最重要的一件： 可维护性不取决于技术多新，而取决于“谁都能看懂发生了什么” 。MVC的View源码就是HTML+少量C#，运维能直接打开.cshtml看逻辑；审计人员能对照RouteConfig确认URL权限；甚至产品经理都能指着@Html.TextBoxFor(m => m.Amount)说“这里就是填金额的地方”。这种透明度，在微服务时代反而成了奢侈品。

所以，当有人问我“现在还学MVC有意义吗”，我的回答是：如果你要维护一个正在跑着的、关系到千万人社保缴纳的老系统，意义重大；如果你在思考“框架设计如何平衡自由与约束”，MVC是本活教材；但如果你只是想学一门能写简历的技术——请直接去学.NET Core或Blazor。因为技术终会过时，而MVC教会我的，是如何在资源受限、规则森严的真实世界里，用最朴素的工程手段，建造一座别人能轻松走进、安心使用的房子。这大概就是“随想”二字的真正分量。