企业官网建设流程全解析

我这两年帮人做代码评审，见过太多团队在MVC和MVP之间反复横跳：有人用Spring MVC写接口，Controller里堆几百行业务逻辑；有人想切到MVP重构客户端，结果界面层又冒出一个四千行的“巨无霸Activity”。这些问题的本质，其实不是框架不好，而是大家没分清MVC和MVP到底在管什么、边界画在哪。

今天这篇就从实际项目的视角，把MVC和MVP这两个架构模式从头到尾拆一遍。先说清楚各自的数据流和角色分工，再放上我整理的七维对比表，最后结合Spring MVC、ASP.NET Core MVC、Android MVP这些真实场景聊选型。文章不会停留在“MVC是Model-View-Controller”这种教科书解释上，我会把Controller和Presenter经常被滥用、被混淆的细节都说透。无论你是在写后端接口、桌面端工具，还是做移动端App，这篇都能给你一个可以直接参考的取舍标准。

1. 先别急着选型，先确定谁说了算

1.1 用餐厅点餐来理解两种模式的核心差异

MVC和MVP名字只差一个字母，但它们的权力结构完全不同。我习惯用餐厅做类比：Model是后厨，负责真实业务数据和规则；View是餐桌上的顾客，只关心菜好不好看、好不好吃；Controller和Presenter都像是服务员，但这两个服务员的权限天差地别。

在MVC里，这个服务员（Controller）负责接收顾客的点单请求，然后跑去后厨下单，后厨做完菜之后，可以自己把菜端出来，顾客（View）也能直接看到后厨做了什么。所以MVC的Model有时候会主动通知View更新，View也可能会去读取Model的状态，Controller的主要工作是“调度”而不是“端菜”。

在MVP里，规则完全变了。View是纯粹的“哑巴顾客”，它自己不能去后厨看菜，也不能感知Model的任何变化。所有的事情都必须通过Presenter这个服务员来传递：顾客按铃（触发事件）→服务员去后厨问（调用Model）→菜做好了服务员再端给顾客（回调更新View）。View和Model之间被硬生生隔开，谁都不能越线。

这就是MVC和MVP最本质的分水岭：View能不能直接感知Model。搞清楚这一点，后面所有的对比、选型、重构方法都有了判断依据。

1.2 “差一个字”为什么会引出这么多坑

很多团队在MVC和MVP之间切换失败，都是因为他们只是把Controller改了个名字叫Presenter，或者把Activity里的代码机械地挪到一个新类里。代码还是那堆代码，职责边界没变，换个马甲自然解决不了问题。

我见过一个实际案例：有个同事用MVP重构一个订单详情页，他确实把逻辑从Activity挪到了Presenter，但Activity里还是保留了对数据库的直接访问，还自己弹Toast、自己跳转别的页面。表面上MVP该有的类都有了，实际跑起来逻辑乱成一团，测试也根本写不了。问题就出在他始终没想明白一个道理：MVP强调的不是“代码搬个家”，而是“权力重新分配”。

所以这篇我不会只给你两个模式的静态定义，而是要把它们各自的数据流、角色边界、常见滥用方式全摊开。下面先拆MVC，再拆MVP。

2. MVC模式拆解：你到底在哪一层写逻辑

2.1 MVC不是只有一个版本，别被Web框架带偏

MVC最早是桌面时代提出的概念，原始的Smalltalk-80 MVC里，View会主动观察（Observer）Model，Model一变，View自动刷新，Controller只负责把用户输入转发给Model。这套机制叫做“主动MVC”，也叫“可观察MVC”。

后来Web框架兴起，由于HTTP请求-响应模型的限制，浏览器里的View不可能实时“观察”服务器上的Model，所以Spring MVC、ASP.NET Core MVC这些Web框架采用的是“被动MVC”变体：浏览器发请求到Controller，Controller调用Service层改Model，再通过返回值渲染一个HTML页面或JSON结果，View永远不会直接感知Model的变化。整个过程中Controller变成了一个“总控台”，重量级明显增加。

这里要提醒一点：很多人把Spring MVC、ASP.NET Core MVC里的“Model”理解为数据库表实体，其实不对。在Web框架语境下，Model泛指业务状态和数据访问后的结果，Controller负责把它转成View能用的展示数据（通常叫DTO或ViewModel）。不要把数据库表和架构模式里的Model画等号，否则会在分层上越写越乱。

2.2 Controller的定位是调度员，不是执行者

Controller在MVC里最容易被写坏。我把它比作十字路口的交警：他指挥车流（数据）往哪走、什么时候停，但车（业务逻辑）本身不是交警开的。

比如在ASP.NET Core MVC里，一个相对合理的Controller方法长这样：

[ApiController] [Route("api/orders")] public class OrdersController : ControllerBase { private readonly IOrderService _orderService; public OrdersController(IOrderService orderService) { _orderService = orderService; } [HttpGet("{id}")] public ActionResult<OrderDto> Get(int id) { var order = _orderService.GetById(id); if (order == null) { return NotFound(); } var dto = new OrderDto { Id = order.Id, TotalAmount = order.TotalAmount, CreatedAt = order.CreatedAt }; return Ok(dto); } }

你看，这个Controller做的事情很有限：接收参数、调用服务、把领域对象转成DTO、返回HTTP结果。真正的价格计算、库存扣减、状态校验都在IOrderService背后的领域逻辑里。这样写的好处是，哪天接口入参变了，或者展示字段变了，你只需要改Controller和DTO，业务核心不受影响。

反过来，如果Controller里出现if (order.Status == OrderStatus.Paid && order.TotalAmount > threshold)这类业务规则判断，你就要警惕了。这些规则应该下沉到Model或Service层，否则每一个新接口都可能复制一遍规则，后面的每次变更都要翻遍所有Controller。

2.3 三层架构和MVC为什么不能混为一谈

因为热词里经常有“MVC三层架构”，这里必须单独说一下：三层架构和MVC不是一回事。三层架构是纵向划分整个系统的层级，通常包括界面层（UI）、业务逻辑层（BLL）、数据访问层（DAL），解决的是“系统分层”问题。MVC则是界面层内部的协作模式，解决的是“UI内部谁管谁”的问题。

你完全可以在一个三层架构的项目里用MVC，也可以不用MVC只用三层。把这两者混在一起，容易导致一种很糟的代码形态：View直接跳过Controller去调用数据访问层，或者在Controller里既写界面逻辑又写数据库访问代码。

更合理的做法是：先用三层架构划定系统的大边界，然后在界面层内部用MVC或MVP来组织交互。Controller/View/Presenter都属于“界面层”的范畴，Service、Repository才属于业务和数据访问层。理解这个边界，你才不会在Controller里写SQL。

2.4 MVC场景里最典型的问题：胖Controller与贫血Model

在Spring MVC和ASP.NET Core MVC的项目里，最常见的坏味道就是“胖Controller”。原因主要有三个：一是把DTO转换逻辑直接写在Controller里；二是把复杂的业务编排写在Controller里；三是把与HTTP请求无关的辅助逻辑（比如导出PDF、发邮件）也塞在Controller里。

我见过有人在一篇文章里问“ASP.NET Core MVC怎么导出PDF”，评论区给出的方案是直接在Controller里用第三方库生成PDF文件再返回。这种写法不是不能用，但会导致Controller承担了文件生成、IO操作、业务查询三大职责。更好的做法是把PDF生成封装成独立的IPdfExportService，Controller只接收请求、调用服务、返回FileResult。这样既好测试，也方便将来替换模板或接入消息队列。

Model贫血的问题更隐蔽。Java和C#项目里常见一种“Model只有属性和getter/setter”的写法，所有业务规则都放到Service里，导致Service变成上帝类。这虽然不违反MVC的明文规定，但等于放弃了面向对象的核心价值。我个人的红线是：Model里至少要保留与自身状态强相关的规则，比如订单是否可取消、账户是否可透支，这些判断放在Model内部，比放在Service里更内聚。

3. MVP模式拆解：让View“闭嘴”的代价

3.1 MVP的三角色到底怎么协作

MVP的三个角色是Model、View、Presenter，其中Presenter是绝对的核心。View要定义一个接口，所有用户操作都通过接口转发给Presenter；Presenter依赖View接口而不是具体实现，拿到用户事件之后去调用Model；Model处理完，Presenter再通过View接口把结果“灌”回界面。

用Android场景最容易理解：Activity或Fragment本身就是一个View实现类，但它不直接操作数据。用户点了一个按钮，Activity调用Presenter.buyButtonClicked(productId)，Presenter去检查库存、调用下单接口，然后弹Toast、刷新页面，这些操作全部通过View接口完成。

所以MVP里的View接口不是可有可无的装饰，它是整个模式的灵魂。没有View接口的MVP是假的MVP，因为一旦你让Presenter直接依赖Activity，Presenter就没法脱离Android环境测试，模式的价值立刻减半。

3.2 Android MVP落地时的代码长什么样

我拿一个订单界面的MVP示例来说，View接口和Presenter的简化写法如下：

public interface OrderContract { interface View { void showLoading(); void showOrder(Order order); void showError(String message); } interface Presenter { void loadOrder(String orderId); void detachView(); } }

public class OrderPresenter implements OrderContract.Presenter { private final OrderContract.View view; private final OrderRepository repository; public OrderPresenter(OrderContract.View view, OrderRepository repository) { this.view = view; this.repository = repository; } @Override public void loadOrder(String orderId) { view.showLoading(); repository.fetchOrder(orderId, new Callback<Order>() { @Override public void onSuccess(Order order) { view.showOrder(order); } @Override public void onError(Exception e) { view.showError(e.getMessage()); } }); } @Override public void detachView() { // 这里要取消异步回调或标记View已销毁 } }

Activity实现OrderContract.View，同时在onCreate里创建Presenter，在onDestroy里调用detachView()。这套写法最大的好处是：OrderPresenter可以在JVM单元测试里用Mock的View和Repository直接跑，不需要启动模拟器，测试速度非常快。

记忆方法：MVC是Controller通过修改Model来影响View，View能看到Model；MVP是Presenter拿着View接口来指挥View，View看不到Model，也不认识Model。

3.3 Presenter为什么会膨胀，以及怎么拆

MVP被很多人诟病“类太多了”，但其实它真正的痛点是Presenter容易膨胀。View越“傻白甜”，Presenter就要承担越多的页面交互编排，比如按钮防抖、表单校验、分页加载、错误提示，全都往Presenter里塞，很快Presenter就能写上一千行。

我的拆解原则是：把“交互编排”和“单个业务动作”分开。比如订单界面不只是“加载订单”，它可能还包含“刷新订单”“取消订单”“重新支付”三个动作。如果这些动作都直接平铺在Presenter里，Presenter会变得很长。我一般会为每个动作抽一个Interactor或UseCase，比如LoadOrderUseCase、CancelOrderUseCase，Presenter只负责串起流程：先调哪个UseCase、数据回来之后更新View的哪部分。

当然，不是所有项目都需要一上来就上UseCase。如果你只是写一个临时工具App，MVP的Presenter直接调Repository也不是不能忍。但一旦发现Presenter开始复制粘贴逻辑，就要立刻考虑抽取UseCase，否则膨胀速度会超出预期。

4. MVC与MVP正面PK：七个维度一次看明白

4.1 核心维度对比速查表

我根据自己的实践经验，把MVC和MVP在七个维度上的差异整理成了下面这张表。你可以把它当成选型时的检查单，也可以贴在代码评审规范里当参考。

4.2 单元测试友好性背后的原因

测试友好性是MVP最大的卖点，这背后有很现实的原因。Web MVC里测试一个Controller，通常要准备MockMvc或者TestServer，把HTTP请求、路由、认证中间件都拉起来，整套环境很重。虽然也能测，但运行速度和隔离性都不理想。

MVP的Presenter则是纯Java或纯C#类，它在构造函数里接收View接口和Repository接口，你在单元测试里随便传一个假对象进去就行。没有网络、没有数据库、没有Android SDK依赖，跑一次只要几毫秒。

我个人的体会是：如果团队有比较强的测试文化，MVP会非常舒服；如果项目基本不写单测，MVP带来的类数量反而会让团队觉得是负担。这也是很多小团队觉得“MVP不如MVC好用”的原因，本质上是测试收益没有兑现。

4.3 平台生态决定选择，而不是谁更先进

MVC和MVP没有先进落后之分，平台生态很大程度上决定了最优解。在Web后端，Spring MVC和ASP.NET Core MVC是事实标准，请求-响应的天然模型和MVC的Controller机制高度匹配，你硬要在后端写MVP反而别扭。在Android原生开发里，早期的Activity生命周期和MVC很难配合好，MVP曾在很长一段时间内是主流实践，因为Presenter把生命周期相关的逻辑从Activity里剥离开了。

近几年的趋势是MVVM或者更前沿的单向数据流方案（比如Compose里的状态管理）逐渐替代MVP在客户端的地位，因为数据绑定框架天然解决了“View更新由谁触发”的问题。但MVP并没有死，大量存量项目还在用，而且如果你能把Presenter组织得足够好，它的可读性并不比MVVM差。

4.4 一句话记住这两者的差别

如果你记不住复杂的对比，就记这一句话：MVC是“View可以看到Model”，MVP是“View只能看到Presenter”。这句话能解决80%的模式判断场景。有人问你这个接口该放Controller还是Presenter，你先看这个动作需不需要直接访问Model数据，不需要的放Controller，需要业务状态参与判断的放Presenter后面再纠结，你对模式的理解已经超过大多数——翻开旧代码一眼就能看出“假MVP”的地方。

5. 实操选型：到底该用MVC还是MVP

5.1 先列判断清单，再做决定

我不会直接告诉你“无脑选MVC”或者“无脑选MVP”，因为选型和团队能力、项目阶段、技术栈强相关。我的判断清单是这样的：

• 你的项目是Web后端接口或服务端渲染页面吗？如果是，大概率选MVC，因为你已经在Spring MVC或ASP.NET Core MVC的生态里。
• 你的界面逻辑复杂吗？比如一个页面有大量相互关联的控件状态、校验规则、动态显隐？MVP比MVC更适合理清这些交互。
• 团队是否习惯写单元测试？如果习惯，选MVP收益大；如果不习惯，MVP会显得笨重。
• 项目是否会长期维护？MVP多出来的Presentation层类和接口需要维护成本，但长期来看，清晰的边界能降低修改风险。
• 你用的是不是一套不支持被动View的UI框架？如果是类似Android原生、WinForms这种事件驱动型界面，MVP/ MVVM比MVC更容易落地。

5.2 典型项目场景推荐表

5.3 从MVC迁移到MVP的三个阶段

如果你已经有一个MVC项目，想逐步向MVP演进，不要想着一天之内全改完。我一般建议分三个阶段走：

第一阶段：抽出View接口。把当前View里所有暴露给外部调用的UI方法（显示加载、显示数据、显示错误、跳转）整理成一个接口，让实际页面实现这个接口。这一阶段不改变整体逻辑，只增加一层抽象。

第二阶段：把Controller里的UI状态逻辑迁到Presenter。比如分页逻辑、表单状态管理、按钮禁用状态，这些属于界面交互状态，非常适合移到Presenter。业务逻辑先不动，留在Service层。

第三阶段：把业务逻辑进一步下沉到Model或Service层。到这一步，Controller基本只剩路由转发，Presenter负责交互流程，Model/Service负责业务规则，MVP的骨架就算立起来了。

这个迁移过程能让你每一阶段都保持代码可运行，而不是“伤筋动骨一百天”。我见过一个团队花了三周就把一个中型WinForms项目从MVC风格改成了MVP风格，靠的就是这种渐进式重构。

6. 常见问题与排查技巧实录

6.1 总觉得“MVC和MVP差不多”，怎么判断

“差不多”这种想法很危险。我提供一个自查动作：随便抽一个界面类，看它有没有直接访问数据层或持有领域Model的引用。如果Activity里直接写orderRepository.fetchOrder(...)，那这就是MVC风格；如果Activity只调presenter.loadOrder(...)，并且所有数据结果都通过接口回传，那才是MVP风格。

还有一种情况更隐蔽：有些人写MVP时，让View接口只负责“刷新UI”，但真正的界面状态（比如当前选中的Tab、输入框内容）还是放在Activity里全局字段上。这说明Presenter没有真正接管交互状态，模式是半吊子。要改也简单，把这些状态提升为Presenter的字段，或者用一个专门的UI状态类来承载。

6.2 Presenter里塞满了业务规则，怎么办

很多人以为MVP就是“所有逻辑都在Presenter”，这是严重误解。我之前提到过拆UseCase的方法，这里再深入一点。区分“业务逻辑”和“交互逻辑”有一个行之有效的标准：这条规则在换一个界面之后是否依然成立。

比如“订单金额必须大于0”是业务规则，因为无论在创建订单页、详情页还是售后页，它都对。把它放在Order的领域方法或下单的UseCase里。而“金额删除按钮在输入框内容为空时置灰”是交互规则，只在当前界面有效，放在Presenter里没问题。

如果Presenter开始出现大量与UI无关的数学计算、价格比较、权限校验，优先抽成独立的服务类。简单说，Presenter的职责是“组织与更新UI”，而不是“成为业务规则的大本营”。

6.3 异步回调导致界面崩溃，是MVP的经典坑

MVP对比MVC多了一个明显的生命周期风险：Presenter里的异步回调（网络请求、数据库查询）可能在你离开页面之后才回来，这时候再去调用View的方法，轻则空指针，重则崩溃。Android场景特别常见。

处理办法有三种：一是Presenter持有WeakReference的View，回调回来先判断是否为空；二是像前面示例那样提供detachView()方法，在onDestroy里把View置空；三是把回调绑定到生命周期，Android里用协程的viewModelScope加Lifecycle.repeatOnLifecycle，或者RxJava的autoDispose。

我自己的习惯是：核心页面用协程加生命周期感知，轻量工具类页面直接WeakReference。不要在View里缓存回调结果，也不要在View不可见时强行弹Toast，这些体验问题都源于异步时未检查生命周期。

6.4 常见问题速查表

6.5 我最后想分享的一个小技巧

不管选MVC还是MVP，我建议你在写任何界面逻辑之前，先画一张“数据流草图”：用户在页面上做一个动作，事件先到谁，谁去拿数据，谁去更新UI。这张草图不用画得多正式，A4纸徒手就能画，但它的价值在于逼你标出每个箭头归属谁。

我在实际项目里发现，很多团队之所以在MVC和MVP之间纠结，根本不是不了解模式定义，而是根本不知道自己的数据流应该长什么样。数据流定了，架构模式其实是顺理成章的结果。

另外还有一个习惯想推荐：给View接口的方法命名时，多用“结果状态”，少用“具体操作”。比如showOrder、showError比runSuccessAnimation、stopProgressBar更容易复用。这也算是我踩过几次坑之后总结的教训吧，写代码的时候舒服，三个月后回来维护的时候更舒服。