Question

在mvc框架中，m与c通讯，通常使用什么方式

Answer 1

其实毫无争议的是，无数个API项目都是和经常变化的屏幕绑定的。你会有很多针对不同平台或终端设备的不同API，甚至Sam Newman将其总结为BFF模式，该模式建议为每个类型的设备或平台开发对应特殊的API，甚至为APP的不同版本。Netflix的Daniel Jacobson将其解释为Experience APIs，无语。

几个月以前，我开始一段思考旅程，思考为什么我们会最终变成这样，我们还能够做些什么？这段思考旅程将我引向了应用架构中最教条的模式：MVC。当我再游历了reactive响应式编程和函数编程等技术思想以后，我开始聚焦简单和业界擅长的偷偷膨胀的过程，我相信你会感兴趣我的发现。

每个屏幕都在使用的模式是MVC，也就是Mode-View-Controller，MVC在没有Web时已经被发明出来，其软件架构是很棒的，起初，厚客户端是直接和一个数据库交互访问通讯，数十年以后，使用了MVC，用于构建OmniChannel 应用。

Angular2即将发布，也许现在是重新评估MVC用途的最好时候，重新评估MVC框架为应用架构带来的价值。

90年代后期，MVC模式被Struts采用到基于Http的Web应用中，今天它是所有应用的基石。

MVC如此光彩照人，以至于react.js只能使用委婉的方式介绍它们的框架似乎偏离了MVC主流：“React is just the View in MVC”.

当我去年开始使用React时，我感觉有些非常不同之处，如果你改变某个地方的一部分数据，那么立即，而且没有视图View和模型Model之间明显的交互，整个UI就改变了，这就是说，我很失望于React的编程模型，变得孤独起来，因为从MVC角度来看，React模型将MVC分离的几个关注混淆在同一个组件中。

作为一个服务器端后端的API设计者，我得出结论，肯定没有好的办法将API调用和React前端协调在一起，精确地说，因为React只注重视图View，竟然没有MVC中的控制器Controller。

Facebook一直拒绝在框架层次弥补这个“缺憾”，React团队首先引入了Flux模式。因为对Facebook的失望， Dan Abramov甚至推荐了另外一个模式：Redux，某种程度上走上了正确方向，但是也没有提供合适方式来连接API和前端。

Answer 2

一、概念 Model = 你的应用程序是什么，是用户界面无关的部分 Controller = 你的应用程序如何将Model显示给用户（UI逻辑），是中心是桥梁，连通Model和View View = Controller的奴才（minion)、小跟班。view一切听从Controller的指挥，并及时将重要事件报告给Controller

二、通信 mvc设计模式,IPhone MVC设计模式要点

1、Model和View永远不能相互通信，只能通过Controller传递。

2、Controller可以直接与Model对话（读写调用Model），Model通过Notification和KVO机制与Controller间接通信。

3、Controller可以直接与View对话（通过outlet,直接操作View,outlet直接对应到View中的控件),View通过 action向Controller报告事件的发生(如用户Touch我了)。Controller是View的直接数据源（数据很可能是 Controller从Model中取得的）。Controller是View的代理（delegate),以同步View与Controller，delegate是一组协议，表示程序将要或者已经处于某种状态时，来调整View，以对用户有个交代。例如系统内存不足了，你是 不是相应的降低view的质量以节省内存。