<p style="text-align: center;"><img src="https://simg.open-open.com/show/0cb4e7689c1957fc3fca2452746d0797.png"></p>    <p>越来越多的前端开发者采用 单向架构 。那么经典的“模型-视图-控制（MVC）”前景如何呢？</p>    <p>为了理解我们是怎么到了现在的境地，不妨回首一下前端架构的演化之路。</p>    <p>过去四年，我倾力于大量的网页项目，花了很多时间做前端架构、将不同的框架整合进来。</p>    <p>2010 年之前， <strong>JavaScript</strong> ——就是那个写出 jQuery 的编程语言——主要用来给传统网站加上 DOM 的操作。开发者似乎并不关心“架构”这个东西。像“ 暴露模块模式 ”对组织我们的代码库就够用了。</p>    <p>如当下关于前端架构与后端架构那样的讨论最早是在 2010 年末段出现，因为那时开发者才开始严肃探讨“单页应用程序”的概念。也是在那时，像 Backbone 、 Knockout 那样的框架开始盛行。</p>    <p>构建这些框架所用的原理在当时颇为新潮，所以设计者不得不从别处取经。服务器端架构已经成熟的做法被他们借鉴了过来。而当时服务器端所有流行的框架无不用到了 MVC 模型（ 因为有多种衍变 ，也叫做 MV*）。</p>    <p>React.js 以“渲染库”身份首次亮相时，遭受了众多开发者的讥讽，他们认为 React 用 JavaScript 处理 HTML 的方式“一反直觉”。然而他们忽略了 React 的一个重要贡献——将 <strong>基于组件的架构</strong> 带到前端世界。</p>    <p>React 并不是“组件”的发明者，但它的确在这领域深凿了一步。</p>    <p>非死book 把 React 当作“MVC 中的 V”来宣传，恐怕也是忽略了它在架构上作出的重大突破。</p>    <p>说句题外话，至今我还对评阅一个 Angular 1.x 和 React 并存 的代码库心有余悸。</p>    <p>2015 年，我们的思维方式有个大跳变——从熟悉的 MVC 模式转向 <strong>单向架构和数据流</strong> ，它发源于 Flux 和 “函数响应式编程”（Functional Reactive Programming），支持的工具有 Redux 和 RxJS 。</p>    <h3><strong>那么 MVC 到底哪里出了毛病？</strong></h3>    <p>也许 MVC 依旧是服务器端的最佳实践。如 Rails 、 Django 这样的框架用起来不失为一种乐趣。</p>    <p>问题的根源，是 MVC 在服务端引介进来的原理和分离做法到了客户端并不完全一样。</p>    <p>控制层-视图层的耦合</p>    <p>下面的图解释了在服务器端视图层是如何与控制层交互的。它们之间只有两处接触，都在客户端与服务器端彼此的边界上。</p>    <p style="text-align: center;">服务器端的 MVC： <img src="https://simg.open-open.com/show/12ddfda82a0d2a0baf12eb7c0726d549.png"></p>    <p>但你来看客户端的 MVC ，就会发现问题。控制器很像我们所说的“背后的代码”，极度依赖前面的视图层。而在绝大多数框架中，控制器甚至是在视图层创建的（比如 Angular 的 ng-controller 就是这样的）。</p>    <p style="text-align: center;">客户端的 MVC： <img src="https://simg.open-open.com/show/3117bddb3887d98fdb6f0cf891bde5da.png"></p>    <p>此外，你再想想 单一职责原则 ，客户端的 MVC 明显打破了这条原则。客户端的控制器代码在某种程度上既负责了 <strong>事件处理</strong> 又在掺和 <strong>业务逻辑</strong> 。</p>    <p>“臃肿的模型层”</p>    <p>细想一下在客户端你放入模型层的数据是什么样的？</p>    <p>其一，你有一些如 users 、 products 那样的数据，代表你的 <strong>应用程序状态</strong> 。再者，你还需要保存 <strong>UI 状态</strong> ——像 showTab 、 selectedValue 那样的东西。</p>    <p>跟控制器类似，模型层也打破了单一职责原则，因为你没有方法将 <strong>UI 状态</strong> 和 <strong>应用程序状态</strong> 的管理分离开来。</p>    <h3><strong>那么“组件”又有什么独到之处呢？</strong></h3>    <p>组件就是 <strong>视图</strong> + <strong>事件处理</strong> + <strong>UI 状态</strong> 。</p>    <p>下面的示意图展示的是如何分离原始的 MVC 模型以实现组件。红线以上的部分正是 <strong>Flux</strong> 所致力解决的：管理 <strong>应用程序状态</strong> 和 <strong>业务逻辑</strong> 。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/9c0b14731e3915b54b7b97e04f23c9a7.png"></p>    <p>随着 React 和 <strong>基于组件的架构</strong> 的流行，我们见到越来越多人使用 <strong>单向架构</strong> 来管理应用程序状态。</p>    <p>它们两者如此契合，其中一个原因是它们完全涵盖了经典的 MVC 方法，并且在构建前端架构时提供了更好的方法来分离项目要点。</p>    <p>然而这不再是 React 的独家特色。看看 Angular 2 ，你就会发现它也应用了完全一样的模型，尽管你可能对管理应用程序状态有不同看法，如 ngrx/store 。</p>    <p>MVC 过去在客户端所能做的已经做到最好了。但从一开始它便注定落败，我们仅仅需要一些时日才能看透。经过这五年的发展，前端架构演变成现如今的模样。你回首一下，花五年时间等来一个最佳实践的横空出世也不算太长吧。</p>    <p>MVC 在最初是很有必要的，因为我们的前端应用程序越来越庞大、越来越繁杂，我们不知道该如何组织它们。我觉得 MVC 做了它该做的，是时候功成身退了；同时也留下了前车之鉴，关于把一种环境（服务器）的好做法移植到另一种环境（客户端）的前车之鉴。</p>    <h3><strong>未来偏向哪种架构？</strong></h3>    <p>我认为短时间内我们不会再回到经典的 MVC 架构来开发前端应用程序。</p>    <p>当越来越多的开发者见识了组件和单向架构的长处，大家的焦点就会沿着这条路向前聚集到如何开发更好的工具和库上面。</p>    <p>这类架构会是接下来五年内最好的解决方案吗？——很有可能，不过话又说回来，没有什么是绝对肯定的。</p>    <p>五年前，没人能够预测我们如今会如何写应用程序。所以我觉得现在就对未来下定论不太保险。</p>    <p> </p>    <p>来自：http://www.zcfy.cc/article/is-model-view-controller-dead-on-the-front-end-1603.html</p>    <p> </p>