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

20-06-09 banq

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. 一个前端框架:最受欢迎的竞争者是AngularVue.jsReact

这不少于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框架集成

 

              

猜你喜欢