为什么我不再使用MVC框架？ _MVC框架

原创：张卫滨译

Jean-Jacques Dubray是一名资深工程师，他最近引入了一个新的模式：状态-行为-模（State-Action-Model，SAM）。SAM是一个函数式反应型的编程模式，它致力于简化数据Model和View之间的交互。它究竟有何优点值得作者弃用MVC呢？
话题起因
在我最近的工作中，最让人抓狂的就是为前端开发人员设计API 。我们之间的对话大致就是这样的：

开发人员：这个页面上有数据元素x,y,z…，你能不能为我创建一个API，响应格式为{x: , y:, z: }我：好吧

我甚至没有进行进一步的争论。项目结束时会积累大量的API，这些API与经常发生变化的页面是关联在一起的，按照“设计”，只要页面改变，相应的API也要随之变化，而在此之前，我们甚至对此毫不知情，最终，由于形成因素众多且各平台之间存在些许差异，必须创建非常多的API来满足这些需求。
Sam Newman甚至将这种制度化的过程称之为BFF模式，这种模式建议为每种设备、平台当然还包含App版本开发特定的API 。Daniel Jacobson在接受InfoQ的采访时曾指出，Netflix颇为勉强地将“体验式API”与“临时API（Ephemeral API）”划上了等号。唉……
几个月前，我开始思考是什么造成了如今的这种现象，该做些什么来应对它，这个过程使我开始质疑应用架构中最强大的理念，也就是MVC，我感受到了函数式反应型编程（reactive）的强大威力，这个过程致力于流程的简化，并试图消除我们这个行业在生产率方面的膨胀情绪。我相信你会对我的发现感兴趣的。
MVC的辉煌过去与现存问题
在每个用户界面背后，我们都在使用MVC模式，也就是模型-视图-控制器（Model-View-Controller）。MVC发明的时候，Web尚不存在，当时的软件架构充其量是胖客户端在原始网络中直接与单一数据库会话。但是，几十年之后，MVC依然在使用，持续地用于OmniChannel应用的构建。
Angular 2正式版即将发布，在这个时间节点重估MVC模式及各种MVC框架为应用架构带来的贡献意义重大。
我第一次接触到MVC是在1990年，当时NeXT刚刚发布Interface Builder（让人惊讶的是，如今这款软件依然发挥着重大的作用）。当时，我们感觉Interface Builder和MVC是一个很大的进步。在90年代末期，MVC模式用到了HTTP上的任务中（还记得Struts吗？），如今，就各个方面来讲，MVC是所有应用架构的基本原则。
MVC的影响十分深远，以致于React.js在介绍他们的框架时都委婉地与其划清界限：“React实现的只是MVC中视图（View）的部分” 。
当我去年开始使用React的时候，我感觉它在某些地方有着明显的不同：你在某个地方修改一部分数据，不需要显式地与View和Model进行交互，整个UI就能瞬间发生变化（不仅仅是域和表格中的值）。这也就是说，我很快就对React的编程模型感到了失望，在这方面，我显然并不孤独。我分享一下Andre Medeiros的观点：

React在很多方面都让我感到失望，它主要是通过设计不佳的API来引导程序员[…]将多项关注点混合到一个组件之中。

作为服务端的API设计者，我的结论是没有特别好的方式将API调用组织到React前端中，这恰恰是因为React只关注View，在它的编程模型中根本不存在控制器。
到目前为止，Facebook一直致力于在框架层面弥合这一空白。React团队起初引入了Flux模式，不过它依然令人失望，最近Dan Abramov又提倡另外一种模式，名为Redux，在一定程度上来讲，它的方向是正确的，但是在将API关联到前端方面，依然比不上我下面所介绍的方案。
google发布过GWT、Android SDK还有Angular，你可能认为他们的工程师熟知何为最好的前端架构，但是当你阅读Angular 2设计考量的文章时，便会不以为然，即便在Google大家也达成这样的共识，他们是这样评价之前的工作成果的：

Angular 1并不是基于组件的理念构建的。相反，我们需要将控制器与页面上各种[元素]进行关联（attach），其中包含了我们的自定义逻辑。根据我们自定义的指令如何对其进行封装（是否包含isolate scope？），scope会进行关联或继续往下传递。

基于组件的Angular 2看起来能简单一点吗？其实并没有好多少。Angular 2的核心包本身就包含了180个语义（semantics），整个框架的语义已经接近500个，这是基于html5和css3的。谁有那么多时间学习和掌握这样的框架来构建Web应用呢？当Angular 3出现的时候，情况又该是什么样子呢？