Angular JS的Java起源：Angular vs JSF vs GWT-CSDN博客

超级英雄的Javascript框架需要一个良好的起源故事。让我们尝试将其修补在一起，同时探讨在企业Java世界中使用Angular JS以及Angular在MVC上的应用。

这篇文章将讨论以下主题，并以一个示例结尾：

Angular JS的Java起源
Angular vs JSF
Angular vs GWT
Angular vs jQuery
MVC（或MVW）的角度分析
MVC中的M –范围
MVC中的V –指令
MVC中的C –控制器

Angular JS的起源

Angular正在成为在企业环境中开发Web应用程序的首选框架，传统上，后端是用Java构建的，而前端则是基于Java / XML的框架（如JSF或GWT）构建的。

随着Java开发人员经常生活在Spring / Hibernate世界中，我们可能想知道基于依赖注入，基于脏检查的MVC框架如何设法从服务器跳入我们的浏览器，并发现这是一个有趣的巧合。

角背后的故事

事实证明，相似之处并非巧合，因为Angular的根源是Google的Java开发人员开发的，他们认为使用Java（特别是GWT）构建前端应用程序的效率不高。

以下是Angular开发人员关于Angular起源的一些重要报价，最近在Javascript Jabber Podcast上（此处的脚本链接）：

我们在GWT中构建了一些东西，而我的工作效率却变得非常沮丧。

我们可以比在GWT中构建应用程序（Google反馈）快得多。

因此，这意味着Angular由全职的Java GWT开发人员有效地创建，以回应他们对Java框架限制前端开发生产力的看法。

JSF还是GWT还是要走的路？

尽管使用两种截然不同的方法，但是JSF和GWT的主要目标之一是通过允许在Java / XML世界中进行Web开发来抽象至少一部分Web。

但是似乎在HTML5浏览器的当今时代，像JSF / GWT这样的框架比它们最初试图抽象的基础平台要复杂得多。

尽管可以使它们工作正常，但问题是：以什么代价？

底层的浏览器技术通常会泄漏给开发人员，最终最终无论如何都必须了解HTML，CSS和Javascript，才能实现许多现实世界的要求。

这使开发人员感到奇怪，为什么没有这么多的约束和抽象的中间层就不能直接使用浏览器技术，因为最后实际上并没有逃脱它们。

实际上，浏览器技术比任何Java框架都更简单，更广泛且文档更丰富。

JSF和GWT的历史背景

重要的是要首先意识到JSF / GWT是如何诞生的：创建它们是为了在已经存在用Java / XML内置企业后端的场景中使用，并且需要重用同一组企业开发人员来构建也是前端。

从项目管理的角度来看，乍看起来直到今天仍然有意义。

同样从历史的角度来看，JSF / GWT是在上下文中创建的，该上下文中的浏览器是一个比当今更加古怪的平台，并且可用的开发人员工具要少得多。

因此，该框架的目标是至少抽象一些浏览器技术，以使其能够被更多的开发人员使用。

Angular vs JSF

十年前，在Ajax出现在Web开发领域的同时，JSF或多或少地出现了。 JSF的最初版本并不是在考虑Ajax的情况下设计的，而是旨在作为一个完整的页面请求/响应模型。

在此模型中，内存中存在代表用户界面的类似于DOM的组件树，但是该树仅存在于服务器端。

然后，服务器View来回转换为HTML，CSS和Javascript，将浏览器主要视为呈现平台，没有状态并且对所发生的事情的控制有限。

在将页面发送给用户之前，通过一组称为Renderers的特殊类将服务器的View表示形式转换为HTML，CSS和Javascript来生成页面。

JSF如何工作？

然后，用户将与页面进行交互并通常通过HTTP POST发送回一个动作，然后通过JSF Controller触发服务器端生命周期，该生命周期将还原视图树，将新值应用于视图并验证它们，进行更新域模型，调用业务逻辑并提供新视图。

然后，该框架在JSF 2中进行了演化，以支持本机Ajax和无状态Web开发，但是仍然可以从服务器端模型在浏览器中生成HTML的主要方法。

Angular与JSF相比如何

主要的设计差异是在Angular中，模型，视图和控制器从服务器移至浏览器本身。

在Angular中，不应将浏览器技术视为要避免或隐藏的东西，而是要在其全部功能范围内使用的东西，以构建更类似于Swing胖客户端而不是网页的东西。

Angular并没有强制要求这样做，但是服务器通常只有很少甚至没有状态，并且主要通过REST服务提供JSON。

Javascript在JSF中有多重要？

JSF对Javascript的采用似乎是该语言是JSF库开发人员需要了解的东西，但通常不是应用程序开发人员。

最广泛的JSF库Primefaces内部包含数千行Javascript代码，这是基于jQuery的前端小部件的，但是基于Primefaces的项目在应用程序代码本身上通常很少甚至没有Javascript。

尽管如此，为了在Primefaces中进行自定义组件开发，了解Javascript和jQuery很重要，但是通常只有一小部分应用程序团队需要了解它。

Angular vs GWT

随着GWT的到来，第二代在浏览器上进行Java Web开发。在GWT中，模型，视图和控制器也被移动到浏览器，就像在Angular中一样。

主要区别在于处理Javascript的方式：GWT提供Java到Javascript编译器，它将Javascript视为客户端字节码执行引擎。

在此模型中，开发完全是用Java进行的，并且通过构建过程将代码编译为Javascript并在浏览器中执行。

GWT采用HTML和CSS

在GWT中，尽管向用户提供了XML名称空间以布局至少一些页面主要块，但HTML和CSS并不意味着对开发人员完全隐藏。

当达到表单级别时，将提供一个HtmlPanel ，以允许直接用HTML和CSS构建页面。在JSF中，这也是可行的，尽管在这两种框架中，通常开发人员都试图通过最大程度地使用XML名称空间来避免使用HTML和CSS。

为什么要使用Javascript进行翻译？

GWT在某些方面与Angular并没有太大不同：它是浏览器中的MVC，其中Javascript是一种翻译目标，而不是应用程序开发语言。

这种移植的主要目标是再次使用同样构建后端的同一开发人员团队，并抽象化浏览器怪癖。

GWT面向对象的方法有帮助吗？

GWT编程模型意味着从面向对象的角度查看网页：在程序中，该页面被视为互连对象的网络而不是文档。

文档和元素的概念被框架隐藏了，但是事实证明，这种额外的间接访问级别虽然足够熟悉，但最终没有那么有用，并且经常比其他任何方式更妨碍开发人员。

是否需要额外的抽象层？

事实是，页面和元素的概念已经足够简单和强大，因此它们不需要多余的抽象层。

通过页面的面向对象抽象，开发人员常常不得不通过无数类的调试来完成一些简单的事情，例如查找在何处添加或删除简单CSS类或将元素包装在div中。

Super Dev Mode可以提供帮助，但是感觉就像对象的整个GWT层次结构，Java到Javascript编译器以及几个调试模式以及浏览器和IDE插件生态系统相比，它们要隐藏起来要复杂得多。：网络。

Angular vs jQuery

同时，在Javascript世界中，同时出现了一种解决浏览器差异的新方法：可以创建一个Javascript库的想法，该库提供了一个可在所有浏览器中正常工作的通用API。

该库将在运行时检测浏览器并在内部调整所使用的代码，以便在所有浏览器中都可以得到相同的结果。

这样的库不需要浏览器的特殊知识，使用起来会简单得多，并且可以吸引更广泛的开发基础。

这些库中最成功的是jQuery，它主要是页面处理库，但它并不意味着它是MVC框架。

Java世界中的jQuery

jQuery仍然是最受欢迎的JSF框架：Primefaces的客户端基础。 Angular和jQuery之间的主要区别在于jQuery中没有Model或Controller的概念，而是直接对文档进行操作。

如果使用jQuery，则会编写很多类似的代码（例如Primefaces Javascript autocomplete小部件中的示例）：

this.itemtip = $('<div id="' + this.id + 
'_itemtip" class="ui-autocomplete-itemtip 
ui-state-highlight ui-widget 
ui-corner-all ui-shadow"></div>')
.appendTo(document.body);

如我们所见，Primefaces开发人员本身需要了解HTML，CSS和Javascript，尽管许多应用程序开发人员都使用提供的XML标记来包装前端小部件，并将其视为黑盒。

这种类型的代码使人想起最初使用Java开发编写的代码，当时Servlet API出现了，但是还没有任何JSP：

out.println(" " + message + "");

Angular允许的是将模型与视图分离，然后将两者与控制器松散地粘合在一起。

Angular JS采用MVC（或MVW）

Angular将自己定位为MVW框架-模型，视图，任意。这意味着它承认模型的明确分离，该模型可以是特定于View的模型，而不必是域模型。

在Angular中，模型只是POJO –普通的旧Javascript对象。

Angular还承认存在View，该View以声明方式绑定到Model。视图只是HTML，带有用于模型和用户交互绑定的某些特殊表达语言，以及称为指令的可重用组件构建机制。

它还承认需要将模型和视图粘合在一起，但是它确实将此元素命名为“ Wathever”。在MVC中，此元素是Controller，在MVP中，它是Presenter，等等。

最小角度示例

让我们看一下MVC的三个元素，并通过使用最小的交互式乘法示例（在jsFiddle中工作）来查看它们在Angular中的对应关系。

如您所见，一旦两个因素发生变化，结果就会立即更新。在诸如JSF或GWT之类的系统中执行此操作将需要大量工作。

在JSF和GWT中，它将是什么样？

在JSF中，例如在Primefaces中，这意味着必须编写一个小的jQuery插件或例程来添加交互式乘法功能，创建facelet模板，声明facelet标签并将其添加到标签库中，等等。

在GWT中，这将意味着引导示例应用程序，创建UI绑定程序模板，在两个字段中添加侦听器或设置编辑器框架等。

提高开发人员的生产力

我们可以看到Angular JS开发人员提高生产力的意义，因为完整的Angular版本如下，只需几分钟即可编写：

<div ng-app="Calculator" ng-controller="CalculatorCtrl">
    <input type="text" ng-model="model.left"> * 
    <input type="text" ng-model="model.right"> = 
    <span>{{multiply()}}</span>
</div>
 
angular.module('Calculator', [])
    .controller('CalculatorCtrl', function($scope) {
        $scope.model = {
            left: 10,
            right: 10
        };
 
        $scope.multiply = function() {
            return $scope.model.left * 
                    $scope.model.right;
        }
    });

因此，让我们从M开始研究此示例代码的MVC设置。

MVC中的M –角度范围

Angular中的模型只是一个简单的Javascript对象。这是模型对象，被注入到范围中：

$scope.model = {
    left: 10,
    right: 10
};

将模型注入到合并范围中会对其进行脏检查，以便将模型中的任何更改立即反映回视图。在上述示例的情况下，编辑因子输入框会触发脏检查，从而触发乘法的重新计算，并立即反映在结果中。

MVC中的V –增强HTML

Angular中的视图只是用特殊的表达式语言（例如multiply()字段的定义multiply()注释HTML。在这种情况下，HTML实际上是充当客户端模板，可以将其拆分为称为指令的可重用HTML组件。

MVC中的C –角度控制器

CalculatorCtrl是示例应用程序的控制器。它在渲染视图之前初始化模型，并通过定义乘法函数充当视图和模型之间的粘合剂。

控制器通常在模型上定义触发事件驱动代码的观察者。

结论

看来，用Java和Javascript进行多语种开发对于企业开发的未来是可行的选择，而Angular是关于如何构建企业应用程序的主要观点。

它带来的简单性和开发速度对前端Java开发人员具有吸引力，无论如何，前端Java开发人员在某种程度上已经需要处理HTML，CSS和通常的Javascript。

因此，一个有吸引力的选择似乎是，一部分企业应用程序代码将开始使用Angular而不是Java用Javascript编写，但是只有接下来的几年才能证明这一点。

使用Angular的另一种方式

另一种可能性是，诸如JSF之类的框架在内部使用Angular作为内部实现机制。

例如，见这个职位从Primefaces项目的领导：

我计划添加内置的js mvc框架支持，可能会有些角。

因此，有可能将Angular用作技术的实现机制，这些技术将遵循使应用程序开发人员的体验尽可能保持基于Java和XML的方式。

似乎可以肯定的是，作为应用程序MVC框架或基于Java / XML框架的内部细节的Angular似乎很慢，但无疑使其进入了企业Java世界。