【译】MVC 在前端已死？

原文：https://medium.com/@alexnm/is...

随着愈来愈多的前端开发开勇单项数据流架构，有些人就开始考虑传统的 MVC 是否还有将来？为了便于理解，咱们首先分析一下前端架构的发展史。

在过去的 4 年里，我看过许多 web 项目并花了大量的时间在前端架构或是为它整合一些框架。在 2010 年前，JavaScript（实现 jQuery 的语言）在传统 web 应用中被普遍用于 DOM 操做以及添加一些简单的东西。人们并不关心架构方面的东西，一些 简单的模块化方式 彷佛已经足够用于设计咱们的代码了。

前端架构 vs 后端架构的讨论随着单页应用这个概念的出现而爆发了，随之出现的框架有好比：backbone 和 knockout。因为当时感念也都比较新，因此框架的设计者们不得不去其余地方获取灵感，因此他们借鉴了一些来自后端架构中的实践，而几乎全部的知名后端框架都是传统 MVC 的实现，因为其中的 一些小差别，也能够被叫作 MV*。

当 React.js 第一次以一个 View 层渲染库出如今人们眼前时，它因为将 HTML 和 JavaScript 写到一块儿的这种非直观方式而被嘲讽。但人们忽视了 React 带来的重要贡献 —— 基于组件架构。React 并无发明组件的概念，但它让组件开发更进一步。当 Facebook 在介绍 React 时将其称为 “V in the MVC” 时，这一架构上的重大突破甚至连 Facebook 也忽视了。顺便说一句，在 review 完一份 同时使用了 Angular 1.x 和 React 的代码库 后，我直到如今还在作恶梦。

不过在 2015 年，随着 Redux 和 RxJS 的使用，Flux 和函数式响应式编程（FRP）将咱们从习惯上的传统 MVC 的思惟模式转变到 单项数据流架构。

那 MVC 到底问题在哪里？

固然，MVC 做为一个架构模式已经被开发使用了至关长的时间，同时也能够被使用与 web 开发。不要误会，MVC 如今依然是后端开发中最好的模式，像 Rails 和 Django 等框架都很乐意使用这种模式。

但问题在于，MVC 在后端的使用的原则与分层方法与前端是不一样的。

控制器与视图耦合（Controller-View coupling）

从下图能够看到视图层和控制器在服务器端是如何交互的，它们仅有两个接触点，都跨越了客户端和服务器端的边界。

当咱们将 MVC 放到客户端，这就有问题了。控制器相似与咱们所知的 code-behind。控制器是高度依赖视图的（见下图），在一些框架的实现中，它甚至是被视图建立的（好比：ng-controller）。

另外，当你从单一职责原则（SRP）的角度考虑，这显然不知足。客户端的控制器代码同时进行了 事件响应 和 业务逻辑。

胖模型（The fat Model）

考虑一下你在客户端存储的是何种模型。一方面咱们有一些数据相似于 users 或 products 表明咱们的应用状态（Application State）。另外一方面，咱们须要存储一些 UI 状态，好比 Tab 是否显示（_showTab_）或者当前选中的值（_selectedValue_）。

相似于控制器，模型也在违反单一职责原则（SRP），由于咱们没有一个好的办法将 UI 状态和应用状态分开管理。

那什么是适合组件的模型呢？

一个组件就是：视图 + 事件响应 + UI 状态。

下图展现了咱们如何真正的将 MVC 的模型分离成组件。然而红线上方的部分，正是 Flux 尝试去解决的：管理 应用状态 和 业务逻辑。

随着 React 以及基于组件的架构的流行，咱们看到单项数据流在管理应用状态方面的崛起。这二者能够如此方便的配合在一块儿使用是由于它们彻底覆盖了原先的 MVC 的方式，并提供了一个对前端架构而言更好的关注点分离的方案。

不过不久后这就不止 React 了。若是你看过 Angular 2，你会发现它采起了彻底相同的模式，不过你也能够用不一样的方案来管理应用状态，好比 ngrx/store。

如今真的没有能作的更好的了，MVC 在起初就注定失败。咱们须要时间来探索，这是一个 5 年的发展过程才将前端架构发展到今天。想一想看，5 年其实对一个最佳实践的创建来讲不算很长。

MVC 在起初是必要的，由于咱们那时不知道在应用愈来愈庞大和复杂的时候，要如何组织咱们的前端应用。我以为它已经达到了起初的目的，并且也能够学习到，若是是从一个上下文（服务器端）应用到另外一个（客户端）的时候，MVC 会是一个最佳实践。

因此,将来将会是什么？

对咱们的前端应用来讲，我不认为咱们会很快回到传统的 MVC 架构。随着也来越多的开发者开始发现组件和单项数据流架构的优点时，关注点会被放在如何基于这条道路建设更好的工具和三方库。

那这类架构回事将来 5 年最好的解决方案吗？颇有多是这样，可是将来没有东西是肯定的。5 年前，没有人能预测如今咱们是如何写应用的，因此如今咱们也不敢这么说。