Home

前端 MVC 已死?【译】

分类: 前端

Imgur

随着越来越多的前端开发人员采用单向数据流架构,人们不禁要问经典 MVC 架构是否还有未来。

为了理解我们如何获得这一观点,让我们分析一下前端架构的演变。

在过去的四年里,我看到了大量的Web项目,花了一段很长的时间来构建前端或集成一些框架进去。

在2010年之前,JavaScript - 用jQuery来写的编程语言 - 主要用于DOM操作。人们不太在意架构,例如显示模块模式足以构建我们的代码库。

关于前端与后端架构的整个讨论实际上随着单页应用概念(2010年末)的兴起以及诸如 backbone 和 knockout 框架的日益普及而出现。

由于这是前端一个新颖的时代,这些框架的设计者必须寻找其他地方的灵感,所以他们借鉴了已经建立良好的服务器端架构的实践。在那时,所有流行的服务器端框架都有一些经典MVC(模型 - 视图 - 控制器)的实现,也被称为MV *,因为都是不同的变体。

当 React.js 最初作为一个视图库引入时,它被许多人嘲笑,因为在 JavaScript中处理HTML的表面上是直观的。但人们忽视了 React 提供的最重要的贡献 - 基于组件的架构。

React 没有发明组件,但它把这个思想更进一步。

这个在架构领域的重大突破差点就被忽略即使是Facebook 生产的,当时他们把 React 作为“V in the MVC”。作为一个附注,我仍然有噩梦,在审查一个代码库后,发现 Angular 1.x 和 React 一起工作。 然而,2015年给我们带来了心态的重大转变,从我们常用的经典 MVC,到使用Redux或RxJS等工具从 Flux 和函数响应式编程的单向架构和数据流。

那么,MVC的问题是什么呢?

当然,MVC作为一种架构模式是很久以前发明的,同时已经适应了web 的一开发规则。并且不要误会我,MVC 仍然可能是最好的方式来处理服务器端。像Rails和 Django 这样的框架是一种高效的工作。

问题是,MVC在服务器上引入的原则和分离在客户端上不一样。

控制器 - 视图耦合

下面您将看到一个关于 View 和 Controller 如何在服务器上交互的图。在它们之间只有两个接触点,两者都穿过客户端和服务器之间的边界。

Imgur

当我们在客户端上移动 MVC 时,有一个问题。控制器类似于我们所知的“代码隐藏”。控制器在视图和大多数框架实现中高度依赖(见下图),它甚至由View(例如:ng-controller)创建。

Imgur

此外,当你想到单一责任原则时,这显然违反了规则。客户机控制器代码在一定水平上处理事件处理和业务逻辑。

胖模型

想一想在客户端模型中存储的数据类型。

一方面,我们有用户和产品的数据,代表我们的应用程序状态。另一方面,我们需要存储UI状态,比如 showTab 或s electedValue。

与控制器类似,模型打破了SRP,因为我们没有一种单独的管理UI状态和应用程序状态的方法。

那么组件如何适应这个模型呢?

组件简单:视图+事件处理+ UI状态。

下图显示了我们如何实际拆分原始的MVC模型以获取组件。此外,线上留下的是Flux正在尝试解决的问题:管理应用程序状态和业务逻辑。

Imgur

随着React和基于组件的体系结构的普及,我们看到了用于管理应用程序状态的单向体系结构的兴起。

两者一起这么好的原因之一是它们完全覆盖了经典的MVC方法,并且在构建前端架构时它们提供了更好的分离关注点。

但这不再是React的故事。如果你看看Angular 2,你会看到完全相同的模式,即使你有不同的选项来管理应用程序状态像ngrx /存储。

没有什么可以做得更好。 MVC注定要从头开始失败。我们只需要时间看到这一点,这是一个5年的进化过程,带来前台架构到今天。当你思考的时候,5年不是很长的良好实践建立的时间。

MVC在开始时是必要的,因为我们不知道如何构建我们的前端应用程序,而它们变得越来越大,越来越复杂。我认为它服务于它的目的,同时也提供了一个良好的教训,从一个上下文(服务器)和应用它到另一个(客户端)。

那么,未来是什么呢?

我不认为我们将很快回到我们的前端应用程序的经典MVC架构。 随着越来越多的开发者开始看到组件和单向体系结构的优势,重点将是在这条路径上构建更好和更好的工具和库。

这种架构是未来5年的最佳解决方案吗?这有很大的机会发生,但再次,没有什么是肯定的。 5年前,没有人可以预测我们今天将如何编写应用程序,所以我不认为现在为未来下注是安全的。

原文: https:[email protected]/is-mvc-dead-for-the-frontend-35b4d1fe39ec#.cjxer4bzl