使用Vaadin轻松上网

如果你想从头开始创建一个UI工具包，它看起来一点也不像DOM。Web技术确实不是为应用程序开发而设计的，而是为富文本表示而设计的。事实证明，对于更静态的内容（如网站），基于标记的表示方式更为优越，但应用程序的情况则有所不同。在计算机图形用户界面的早期阶段，用户界面框架并不是偶然形成“基于组件”的库。这些UI库已经开发了几十年，但是基于组件的UI框架的基本概念仍然是创建应用程序最强大的方法。

但是Swing、SWT、Qt和类似的桌面UI框架与web应用相比有一个主要问题：它们要求您在客户机上安装特殊的软件。正如我们在互联网时代学到的，这可能是一个大问题。用户现在使用的应用程序种类繁多，安装所有这些应用程序，尤其是维护这些应用程序，将成为IT部门的负担。

像Java的Applet/javawebstart支持（还有Swing或JavaFX）和Flash这样的浏览器插件是传统的解决方法，可以避免在工作站上安装实际的软件。但其中著名的安全漏洞，尤其是过时的软件，可能会成为一个巨大的问题，你的IT部门现在最有可能反对安装任何类型的第三方浏览器插件。对他们来说，只维护一个浏览器应用程序要容易得多。这就是为什么纯web应用正在征服当今最复杂的应用领域的根本原因之一。

欢迎来到“奇妙”的网络应用世界

即使对于有经验的桌面开发人员来说，从桌面世界到web开发也可能是一个巨大的飞跃。开发web应用程序比开发基本的桌面应用程序要复杂得多。有很多事情使事情变得复杂，例如客户机-服务器通信、用于显示的标记语言和CSS、用于客户机端的新编程语言（JavaScript）以及许多不同形式的客户机-服务器通信（基本http、ajax样式的请求、长轮询、web套接字等）。事实是，即使使用最现代的web应用框架，web开发也不像构建桌面应用那么容易。

Vaadin框架是一个开源的Java框架，与主流web应用世界中基于组件的Swing UI开发最为接近。Vaadin是一个基于组件的UI框架，它试图使web开发和传统桌面开发一样简单，最大限度地提高开发人员的生产力和最终用户体验的质量。在Vaadin应用程序中，您编写的实际UI逻辑存在于服务器的JVM中。Vaadin没有浏览器插件，而是有一个内置的“瘦客户机”，可以在使用原始浏览器技术的浏览器中高效地呈现UI。高度优化的通信通道只将用户屏幕上真正可见的内容发送到瘦客户端。完成初始渲染后，客户端和服务器之间只传输两种方式的增量。

Vaadin框架的体系结构为web开发挑战提供了一个抽象概念，大多数时候，您可能会忘记您正在构建一个web应用程序。Vaadin负责处理所有的通信、html标记、css和浏览器差异—您可以使用干净的Java方法将所有精力集中在域问题上，并利用桌面应用程序的经验。

Vaadin使用GWT实现在浏览器中运行的“瘦客户端”。GWT是另一个类似于web开发的工具，它的核心是Java到JavaScript的“编译器”。GWT还有一个类似Swing的UI组件库，但是在GWT中，Java代码被编译成JavaScript并在浏览器中执行。编译器只支持Java的一个子集，而且它没有在JVM中运行这一事实会导致一些其他限制，但是在它中的概念也是相同的。在浏览器中以白盒的形式运行代码也会带来一些安全隐患。

应该注意的架构差异

每个架构决策都有其优点和后果，在UI层中从Swing切换到Vaadin也是如此。

一个应用实例，多个用户

首先您会注意到，您现在正在数据旁边开发UI。几乎所有现代商业应用程序，包括web和桌面应用程序，都以某种方式将数据保存到中央服务器。通常，数据被业务逻辑层“屏蔽”，例如用ejb实现。现在您开始使用vaadinui，EJB，或者您在“后端”中使用的任何技术，都“更接近”UI。它通常可以在与您的vaadinui非常相同的。应用服务器中运行，这使得一些以前很难解决的问题变得微不足道。使用本地EJB既高效又安全。

即使您仍然为EJB使用单独的应用程序服务器，它们很可能使用快速网络连接到UI服务器，该网络可以比典型的客户机-服务器通信更有效地处理UI和业务层之间的连接–Vaadin瘦客户机的网络要求在大多数情况下要求较低，因此您的应用程序可以在移动网络上使用。

从桌面Java到Vaadin的开发人员很快就会注意到的另一件事是，在服务器端，带有“static”关键字的字段是完全不同的。许多桌面应用程序使用静态字段作为“用户全局”变量。在服务器上运行的应用程序中，它们是“应用程序全局”，这是一个很大的区别。应用服务器通常为每个web应用程序（.war文件）使用类加载器，而不是为每个用户会话使用类加载器。对于“用户全局”变量，应该使用UI类、VaadinSession、HttpSession或@SessionScoped cdibean中的字段。

一般来说，IT部门维护Web应用程序的成本要低得多。传统上，它们是在公司的内部服务器上运行的，但这个时代的趋势是将它们托管在PaaS服务中，或者更普遍地托管在“云”中。与在每个用户的工作站中维护应用程序不同，更新和更改只需要应用到服务器。此外，所有数据（不仅仅是共享部分）都保存在服务器上，而服务器的备份更易于处理。当你的用户的工作站坏了，你可以给他/她一个替换设备，他们可以继续他们的工作。

内存和CPU使用集中在服务器上

消极的一面是，以前由用户工作站完成的一些计算现在被移到了服务器上。CPU命中率通常可以忽略不计，但是如果不考虑这个事实，您可能会面临一些内存限制。另一方面，应用程序内存和处理现在主要在服务器上进行，这可能是一件好事。服务器端方法使得处理非常复杂的计算任务成为可能，即使是使用非常普通的手持设备。当然，这在Swing和中央服务器上也是可能的，但是在Vaadin方法中，这是一个免费的额外特性。

一个典型的Vaadin商业应用程序每个用户消耗50-500kB的服务器内存，这取决于您的应用程序特性。如果你有一个非常小的应用程序，你可以用更小的数字来完成，如果你从你的用户界面引用了大量的数据，这通常会使事情变得更快更简单，你可能需要更多的内存给每个用户。

每个用户的内存使用率与javaee标准JSF一致。如果你做了一些基本的计算，你就会明白这对于大多数典型的应用程序和现代应用服务器来说都不是问题。但是，如果您在应用程序代码中创建了意外的内存泄漏，或者不小心将整个数据库表加载到内存中，那么内存消耗可能比桌面应用程序更早成为一个问题。从一个用户会话中意外引用一百万个基本数据库实体很容易在每个会话中消耗100-200MB的内存。这在桌面应用程序中可能仍然可以接受，但是如果您在服务器应用程序中有多个并发用户这样做，您很快就会遇到麻烦。

内存问题通常可以很容易地通过使用分页或从后端将数据延迟加载到UI来解决。如今服务器容量也非常便宜，因此购买一台效率更高的服务器或将应用程序群集到多个应用程序服务器上，很可能比花几个小时优化应用程序或在其体系结构设计上做出妥协要便宜得多。但是，如果您的每个应用程序用户都需要对大量内存数据集进行大量分析，那么web应用程序仍然不是您的用例的发展方向。

如果你的应用程序的内存使用比它的开发成本要重要得多（阅读：你正在尝试编写下一个GMail），那么Vaadin框架可能不是适合你的应用程序的合适工具。如果您仍然想转到web应用程序，在这种情况下，您应该努力实现完全（服务器）无状态的应用程序，并将UI逻辑保留在浏览器中。GWT（也嵌入到Vaadin中，由Vaadin有限公司支持）是这类应用程序的一个很好的库。