在开发一个媒体播放类App时，你可能会遇到这样的问题：界面要实时更新播放进度，数据来源又来自多个异步接口，这时候该用MVC还是响应式编程？其实，MVC模式和响应式编程并不是非此即彼的选择，它们完全可以一起工作。
MVC本身并不排斥数据流变化
MVC的核心是把界面（View）、数据（Model）和控制逻辑（Controller）分开。比如你在做一个视频播放器，播放状态、进度、字幕信息放在Model里，UI是View，而暂停、快进这些操作由Controller处理。这个结构本身不关心数据是怎么来的，无论是从本地读取，还是网络回调，甚至是从响应式流推送过来的，它都能接住。
响应式编程只是换了一种“通知”方式
传统MVC中，Controller通常通过代理或回调来告诉View更新。而响应式编程，比如使用RxSwift或RxJava，是让数据自己“冒泡”上来。Model变了，直接推给订阅者，View自动刷新。这其实只是把原来的“你告诉我一下”变成了“我自动看到”，并没有破坏MVC的分层。
举个例子，在Android开发中，你可以让ViewModel（虽然听起来像MVVM，但这里可以看作增强型Model）暴露一个Observable，Controller订阅它，一旦有新的播放时间到来，就通知View刷新。代码看起来像这样：
model.currentTimeObservable
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.subscribe(time -> view.updateProgress(time));关键在于谁在“驱动”更新
只要你还保持View只负责显示，Model只管数据，Controller处理交互逻辑，那即使用了响应式，依然是MVC的思路。响应式只是让Controller监听数据更方便了，而不是让它变得臃肿或者让View直接去拉数据。
有些开发者担心响应式会让逻辑太分散，其实只要约定好数据流向，比如规定所有外部事件都由Controller统一处理，再转发给Model，就能避免混乱。就像家里的水管系统，不管水压多大，只要管道设计合理，就不会爆裂。
实际项目中的常见做法
很多成熟的媒体软件，比如音乐播放器或直播App，底层用Retrofit + RxJava拉流数据，上层依然用类似MVC的结构组织页面。Controller持有Observable的订阅，Model提供数据源，View被动更新。这种组合既保证了架构清晰，又提升了异步处理的可维护性。
甚至在一些Objective-C的老项目中，用KVO配合NSNotificationCenter实现类似响应式的效果，本质上也是让MVC“动”起来。现在的响应式框架只不过是把这些机制封装得更干净罢了。