为什么我还是喜欢Vaadin？ - frankel


Vaadin的第一个也是最重要的特征是，不需要了解其他技术。让我们考虑一下由REST API和JavaScript前端组成的“标准”应用需要具备哪些技能：

  1. Java
  2. Jakarta EE API，即 Servlet和JAX-RS或Spring框架
  3. REST原则
  4. AJAX用于浏览器与服务器之间的互通
  5. HTML
  6. CSS
  7. JavaScript（或TypeScript）
  8. 一个前端框架：最受欢迎的竞争者是Angular，Vue.js或React。

这不少于8种完全不相关的技术。
使用Vaadin时，该列表将仅限于Java ...和Vaadin。

我的经历截然不同：我作为承包商工作了15年以上，曾为许多不同的客户服务。大多数开发人员都是普通人，乐于从9点工作到下午5点，然后回到家过上自己的生活。他们既无意愿也无时间在办公时间之外学习另一种技术。

没有整合阶段
Vaadin提供的简单性还有其他好处。如果将一个应用程序的架构分为通过REST API进行通信的前端和后端，则有两种策略可以组织一个团队：

1.基于每层的前后端开发团队
该策略基于两个专业团队，即前端团队和后端团队。它们在自己的堆栈中非常出色。它们都在各自的堆栈中并行工作。在最慢的工作完成后，他们将各自的工作整合在一起。
我的经验告诉我，在并行阶段，这项工作很快就完成了。相反，集成阶段需要很多时间。最糟糕的是，包括项目经理在内的大多数团队都低估了集成阶段。

2.基于每个用例的开发团队
此策略基于全栈开发人员。这种开发人员可以在前端和后端都可以工作。每个开发人员都被分配了一个用例/用户故事，然后需要了解它周围的业务，然后才能够开发从GUI到数据库的整个流程。
我个人认为，全栈开发人员是管理人员提出的使开发人员可互换的概念。这样，任务计划对他们来说变得非常容易。无论如何，让我们承认这样的独角兽确实存在。
在这方面，Vaadin允许非摇滚明星开发人员使用这种策略来开发应用程序。它还使他们可以将更多的时间花在业务方面，而将更少的时间花在技术问题上。

后端和前端开发之间的并行化
使用传统方法，设计人员可以使用HTML和CSS来实现。他们将设计特定的HTML模板和CSS类。然后，将要求开发人员使用它们。
如果需求在中途发生变化，则开发人员将需要停止工作以集成设计人员所需的更改：开发人员的工作流程与设计人员之间存在高度依赖性。诸如JSP，JSF和Thymeleaf之类的某些技术允许开发人员按原样重用设计人员的工件。。在这种情况下，两者都需要处理相同的工件。当人们不能完全掌握上游变化时，Git合并冲突总是很有趣。

Vaadin引入了两个抽象来分离开发人员和设计人员的工作：主题和组件。

  • 一个主题是CSS（Sass）。因为Vaadin生成HTML，所以设计人员知道所需的结构，因此可以相应地设计CSS。
    默认应用Lumo 主题。开箱即用地提供了另一个主题“ Material 材料 ”。生态系统提供了其他主题，每个主题都可以作为JAR使用，只需要添加到类路径中即可。设计师也可以创建自己的设计。
    请注意，可以通过一个简单的方法调用来切换主题。
  • 一个组件既有HTML模板，并表示它在服务器端的Java类。这样的组件可以将其他组件放置在布局中。Java类将它们作为属性进行管理时，HTML模板负责布局。这样，开发人员在Java类（或使用它的任何其他类）上的工作与设计人员在模板上的工作完全相互隔离：它们可以完全并行执行。

专为“业务”应用程序而设计
最后，Vaadin的核心是开发业务应用程序。

  • 在UI端，组件包括此类应用程序中经常使用的小部件，例如字段，组合框，表单，表格等。
  • 大多数组件显示数据。这些组件的设计在组件及其数据之间引入了抽象。有不同的说法：
    1. 对于标量值，例如在字段中显示的电子邮件
    2. 对于集合值，例如在组合框中显示的国家/地区列表
    3. 二维值例如表格数据显示在一个表

反对使用Vaadin的论点
1.能做大型系统？
Vaadin存储服务器端组件的状态。随着组件数量的增加以及客户端数量的增加，这导致了内存的指数消耗。在这方面，传统应用程序与Vaadin应用程序没有太大区别。
首先，我们需要了解，绝大多数应用程序都是有状态的。但是，它们之间的区别因素在于存储状态的位置。如前所述，Vaadin将其存储在服务器上。只有两种其他选择：

  1. 将其存储在数据库中。我需要详细说明为什么这是一个坏主意吗？
  2. 将其存储在客户端上。在客户端上存储与UI相关的数据非常有意义。但是，有一个不小的警告：如果打开了多个选项卡，则需要以某种方式在服务器端进行处理。

超过一万个并发用户可能考虑Vaadin以外的其他选择，99.99％低于这个数字。

2.不是API优先？
我听到反对Vaadin的另一个论点是它不是API优先的。优秀的软件开发人员/架构师始终会开发API，以允许使用不同类型的客户端：浏览器，还包括本机客户端以及其他服务（内部或第三方）。
不幸的是，我认为这是从众心理。在多个客户端的情况下，API-first是可取的。我从事的大多数业务应用程序只是CRUD应用程序，其上面或多或少地应用了业务逻辑。
但是，如果将来有必要增加客户，该怎么办？ YAGNI！如果这样做了，请记住，Twitter能够将其完整的信息系统从Ruby on Rails重写为Java：迁移应用程序的GUI层是在可能的范围之内。

我相信Vaadin如此不受欢迎或不广泛的原因之一是因为它太无聊了。它已经存在超过15年了，它可以按预期运行，并且围绕它的大多数挑战已经解决。
我在十多年前发现了Vaadin，那是一见钟情。实际上，我立即开始修改它，并尝试将其与我的另一个迷恋者Spring框架集成。