Question

为什么我不再使用 MVC 框架

Answer 1

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 出现的时候，情况又该是什么样子呢？
在使用过 React 并了解了 Angular 2 将会是什么样子之后，我感到有些沮丧：这些框架都系统性地强制我使用 BFF“页面可替换模式（Screen Scraping）”模式，按照这种模式，每个服务端的 API 要匹配页面上的数据集，不管是输入的还是输出的。