Get best of the week

现代前端架构（第2部分）

图片

文章“ 当代前端体系结构 ” 的第二部分，从数据流的分布方面讨论了前端体系结构。从这里开始

实作


DOM生成的算法（注入DOM的算法）


jQuery 库引入并掌握的这项技术确实是编写大型客户端应用程序的开始，尽管jQuery并没有解决体系结构问题。当浏览器行为存在太多不一致时，它旨在使操作DOM树更加容易。这提供了与浏览器无关的API。

我认为这不是故意的，但是jQuery简化了DOM API，以至于很难将其与普通的编程语言API区分开。反过来，这允许开发人员从字面上混合DOM API级别（View）和业务逻辑（Model）。

再一次，我们仍然处于同一服务器端MVC的上下文中。这只是一个续集。没有真正的控制反转。对视图/页面的一般控制仍由服务器端代码确定。





在上面的代码段中，将Model，Presentation和Presenter / Controller以某种方式组合为一个整体代码结构。当模型仅包含一个属性时就是这种情况。想象一下，尝试创建一个没有服务器浏览周期（例如SPA）的Web应用程序。以任何方便的方式处理所有这些都是不可能的。与DOM交互的代码被其余的应用程序逻辑所渗透，因此被称为DOM注入算法（我不确定官方是否有这样的术语）

Backbone.js-MV *


如我们所见，在jQuery中，当开发应用程序时，显然没有结构和组织代码的方法。这就是Backbone.js作为下一个进化解决方案出现的地方。它是最早带来客户端MVC样式好处的库之一。



如果我们查看Backbone数据流程图，我们将清楚地看到模型和视图，但是没有等效于控制器的对象。模板在不断发展，客户端MVC只是先前MVC架构的发展。在此演变过程中，许多JavaScript社区都同意模型和视图的定义，但是在控制器上没有达成共识。给定客户端环境，控制器的想法不是很合适。控制器保持打开状态以供解释。

至于骨干网，里面没有控制器。那是什么是MVC，MVP还是MVVM？从服务器MVC的定义中借用，控制器具有两项职责，即：以传入的HTTP请求的形式响应用户操作，并控制模型以创建视图（HTML页面）。对于Backbone，这些职责在View和Router之间共享。但是缺少Controller或Presenter的独立概念。
, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

这就是MV *或Model-View-Whatever（“无论如何”）的诞生方式。要进行详细讨论，强烈建议您查看Addi Osmani的博客，

与以前的jQuery相比，Backbone帮助创建了更多的结构化代码。









在本文前面，我将Backbone称为下一个演化解决方案。原因是他只是扩展了服务器端MVC以对其进行补充。例如，如果我们的服务器是RESTful的，并且暗示前端代码只是在服务器端表示模型的一种手段，则将Backbone预配置为与API同步：



此外，Backbone还内置了许多其他小的约定，就像是扩展一样。最后，我说Backbone可能不是当时唯一的解决方案，但就代码结构和组织而言，这确实是一项开创性的工作。像jQuery一样，它已经被许多产品使用。

Knockout.js-前端的数据绑定


Knockout.js是我们使用基本模板的最新示例。它旨在实现MVVM-JavaScript的Model-View-ViewModel。就是这样。虽然Backbone处理组织和代码结构问题，但Knockout是使用声明性数据绑定的View层的有效实现。声明性绑定的优点与任何声明性编程构造相同：

  1. 易于阅读：声明性代码有助于编程
  2. 缩短标准模板：绑定使我们能够在ViewModel每次更改时自动更新DOM，并且每次View通过用户输入更改时也自动更新ViewModel。
  3. 可观察：淘汰赛为事件提供了更高级别的抽象。这使Knockout可以自动跟踪ViewModel属性之间的依赖关系。如有必要，我们可以订阅Observable属性。





尽管Knockout为View和ViewModel提供了定义明确的构造，但它并没有说明应用程序模型应该是什么。这使得Knockout非常专注和通用，因为它可以用作库而不是框架。从我自己的经验来看，我看到它被用来创建SPA迷你应用程序，其中一个Web应用程序由几个页面组成，每个页面都是一个小的Knockout应用程序。这个答案StackOverflow上明确规定MVVM在淘汰赛范围。
通常认为，在模型中，Knockout位于服务器端。ViewModel只是使用Ajax或其等效项来请求服务器端模型。

Knockout替代了jQuery和模板工具（如Handlebars）进行DOM更新，但仍将jQuery用于动画，Ajax和其他实用程序。与Backbone结合使用，它可以作为MVVM模板的完整实现。从理论上讲，这可能发生，但在此之前，这些概念已经在下一代工具中得到了发展。
从这里开始Angular 1，Aurelia，Ember.js等的革命性运动。

由于其与.NET世界的紧密联系，因此Knockout已被广泛用于ASP.NET MVC应用程序中。像Backbone一样，这是对稍有不同的问题的另一种进化解决方案。同样，客户端代码只是服务器端MVC模式的扩展的假设没有改变。服务器端仍然是主导架构。

Knockout和Backbone都是JavaScript库。一种或另一种方式，将Backbone视为一个框架。为什么？没有确切的答案，但可能是正确的。骨干网由于其对代码结构的重视而一直被更高层次的抽象处理。此外，Backbone从未打算取代无处不在的jQuery（即使在2019年，排名前10,000,000的网站中有70％使用jQuery），而Knockout与jQuery核心重叠，即DOM操作，这自然使Knockout变得复杂。因此，与Backbone相比，淘汰赛的适应性受到限制。但这仍然是前端社区声明式数据绑定的第一个实现，值得特别提及。

Angular 1-给我控制


jQuery是使用DOM进行的，Angular 1是整个前端生态系统的。这永远改变了创建大型客户端应用程序的想法。他提出了许多概念作为基础-模块化系统，依赖项注入，控件反转，更容易的数据绑定等。

那时，要选择正确的JavaScript库并为前端创建完美的技术堆栈，现在仍然是一项艰巨的任务。 Angular 1只是提供了一个更简单但更具凝聚力的选择。关于Ember.js和其他类似系统也可以这样说，但是Angular 1的适用性与当时的替代品在不同的质量上。
从明显的角度来看，Angular 1是一种革命性的解决方案，它明显偏离了简单的服务器端MVC扩展的思想，客户端代码分散在页面之间。Angular 1使SPA成为创建下一代用户体验的几乎事实上的一流解决方案。

框架还是库？


以前的解决方案是库而不是框架。毫无疑问，Angular 1是一个定义明确的结构。平台和库之间的必要区别因素是IOC-控制反转。此外，要使Angular 1成为框架，我们可以注意：

  1. 定义明确的MVVM：Angular 1具有清晰的Model，View和ViewModel对象。
  2. (DI): Angular 1 DI, Model. Angular 1 (Service). , .
  3. (data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
  4. 模块化系统：Angular 1引入了特定于框架的模块化系统。模块是组织几乎每种语言的代码的基础。JavaScript在2015年之前还没有模块化系统（浏览器直到2018年才支持它）。就组织而言，Angular远远领先于它的时间。

同时，Angular 1也因其引入的复杂性而受到批评。最重要的批评是它是基于服务器端设计建模的。这对于前端开发人员而言并不常见。坦率地说，有些事情很糟糕：

  1. 命名空间冲突：尽管DI很棒，但是它是使用使用全局命名空间的Service Locator模式实现的。这使得服务的前缀几乎是强制性的。
  2. . , , , . React . -, .
  3. . , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

还有许多其他小问题。Angular 2，或者仅仅是Angular，是一个完全的突破，就好像它是一个全新的框架一样。除了名称和一些概念外，我发现它们之间没有任何共同点。



多年来，Angular 1出现了一些小的发行版，其中修复了许多小小的使用复杂性。其中最重要的是组件模型的添加，其中大多数前端开发趋势已在其中融合。

Angular 1生活了很长时间，并且继续生活在前端社区中。凭借其所有优点和缺点，它帮助社区了解了软件体系结构的重要性，并为编写可伸缩应用程序提供了基础。它的缺点和不足成为解决未来体系结构问题的基础。

More articles:


All Articles