我应该使用Vaadin Framework吗?

时间:2009-07-26 05:28:03

标签: java gwt web-frameworks vaadin

我只是尝试使用Vaadin Framework,在我看来它很容易使用。另外,我喜欢他的框架是它建立在Google Web Toolkit (GWT)之上。

您如何看待,我应该继续使用此框架,还是最好坚持使用GWT?

18 个答案:

答案 0 :(得分:123)

嘿。作为免责声明,我为开发Vaadin的公司工作。

Vaadin以一种在GWT中预编译的一组组件的方式使用GWT。当然,如果您愿意,您还可以另外制作自己的组件。但是,这组组件非常完整,通常可以根据您的需要进行定制。这意味着每次更改应用程序时都不必将代码从Java重新编译为JavaScript。您只需将已有的组件组合在一起。

框架是服务器驱动的,因此所有逻辑都在服务器端处理。组件有两部分,客户端和服务器文件。客户端只是组件的虚拟“视图”。一旦你与它交互,它就会向服务器发送一条消息,告知这个或那个被按下/写入/等等。然后服务器决定应该做什么。这是为了提高安全性,因为您不能“破解”逻辑,因为在javascript中只有用于发送请求的小API。在某些情况下,这可能与应用程序的速度有一点权衡,但我不认为它是如此糟糕。最糟糕的速度颠簸通常是数据库查询往返等,这与UI框架的选择没有任何关系。所建议的演示的低迷可能是因为你离服务器很远或者目前用户受到很大的打击。在自己的环境中尝试,关闭应用程序的最终应用程序,看看它的执行情况。您可以部署一些现成的应用程序来测试它。

我想这个选择归结为你想要做的事情。 Vaadin适用于Web应用程序,因为您可以轻松构建普通的Java应用程序并为其创建动态Web UI。如果您在传统网站上做更多的事情,用户只能查看页面 - 而不是主动与之交互,那么Vaadin不是最好的方式。与其他一些免费框架(如rails或php框架等)一起使用。我认为你正在做一个应用程序,因为你建议你现在正在使用GWT,所以Vaadin应该是好的。

在这里,在Vaadin论坛或者irc频道#vaadin @freenode上提出更多问题,也许有人可以给你更多理由说明为什么或为什么不使用Vaadin。

答案 1 :(得分:120)

经过近一年的时间开发一个不那么庞大的GWT应用程序,使用我从上一个Google I / O中学到的所有最佳实践,如MVP,EventBus,CommandPattern等。我从内心深处说出这一点:之后花了好几天试图让我的团队和客户在技术上和视觉上都想要的方式,即使在UiBinder发布之后,Vaadin就像隧道尽头的灯光一样来到我身边。

为命令模式编写了将近一千个样板操作,另外一千个演示者和视图以及另外一千个事件处理程序等。不必处理近75%的这些类并仍然保持良好的模式方法(appfoundation add- on),一点网络开销是可以接受的。使用Vaadin,开箱即用,您可以获得良好的小部件,分页,数据绑定,完美的布局。这一切都是为了什么?服务器端的内存消耗量更多。

我想我可以说这是可以接受的,因为我没有建立下一个Facebook或其他东西。我仍然可以为每台中型服务器处理数千个并发用户,同时保持低延迟往返。

使用Vaadin,我可以使用几乎一半的代码行构建一个不错的应用程序,但应用程序似乎仍然更完整。 : - )

!!更新2011年2月23日:我无法强调应该如何了解每个框架的局限性。 Vaadin也不例外。应该知道Vaadin抽象出任何形式的HTML或JavaScript。此外,生成的HTML非常繁重,您应该自己处理历史状态更改。因此,在构建项目时要注意这些开销。

答案 2 :(得分:30)

关于Vaadin的常见讨论涉及小部件集,并担心客户端和服务器之间的往返通信。

但在我看来,这忽略了Vaadin最重要的(也许是革命性的)方面:它完全消除了设计和实现AJAX应用程序通常所需的客户端 - 服务器通信的任务(“A”和“X”)在AJAX)。

使用Vaadin,您可以完全忘记DTO(数据传输对象),基于协议的安全问题,Hibernate延迟加载异常等。

您在某种意义上只是编写一个常规的旧Java Swing桌面应用程序,只是您使用的是Swing中的其他UI工具包。

答案 3 :(得分:17)

根据我的经验,GWT需要很多样板代码,并且在构建复杂且丰富的UI时会变慢。通常我们处理包含许多可持久域对象的非常复杂的应用程序模型。要将所有这些数据带到客户端,您需要引入单独的客户端模型并提供数据转换机制。我们已经将Dozer用于此目的,并且需要花费很多时间来映射每个字段,创建自定义转换器并测试所有这些内容。

另一方面,如果不涉及过度工程,如果应用程序不是很复杂,您可能会利用客户端资源并减少服务器负载。通过这种方式,您可以极大地减少与服务器的通信,并获得更具响应性的软件。

Vadin看起来非常开发人员:)但我有点害怕对服务器的“大规模AJAX攻击”。我有ZK的经验,并且当UI上的一个简单操作工作缓慢因为它需要与服务器通信时,我们经常遇到性能问题。

Wicket是另一个很好的框架,但它更适合网站。它可以使用和不使用AJAX,可以被搜索引擎索引。最有吸引力的是它处理干净的HTML代码 - 没有自定义标签,没有控制结构,严格分离关注点,只有特定的wicketid namigs用于组件。

这主要取决于您的需求:

  1. 如果您需要超快速且简单的应用程序 - 使用GWT并利用客户端资源
  2. 如果你的申请比Vaadin看起来更复杂,那么
  3. 如果您的应用程序是公开的,并且您需要能够为SEO编制索引而不是选择Wicket。

答案 4 :(得分:9)

事情是,为了认真的发展,你不能忘记任何事情,更不用说dtos ..我正在抛弃接缝和服务器端ui概念只是因为我希望更好地控制电线上的内容.. vaa​​din's问题就在于,在服务器端有状态..

答案 5 :(得分:9)

关于Wicket使用会话管理组件状态和可伸缩性的问题与关于Vaadin和服务器端处理的争论类似。在过去的十年中,我了解到Java社区在如何衡量Web框架的潜力(以及其他方面)方面通常是错误的。从JSF到Grails,它通常需要几百GB的内存和至少十二个具有重叠和低效功能的开源jar文件才能运行生产应用程序。环顾四周,您将看到大多数Web托管公司都没有提供实用的Java选项,因为Java技术为Web框架采用了不稳定的路径。由于编译速度的原因,GWT 2.1仍然很难使用,而且从一开始就应该有MVP和数据表。我喜欢Wicket,但Vaadin看起来很有希望......但是知道Java框架是如何进行的,我相信他们会在某些时候自己动手,但我怀疑是因为服务器端处理繁重。

答案 6 :(得分:7)

为了构建外观漂亮的用户界面,我想说这是可行的方法。此外,它有很好的记录。

答案 7 :(得分:6)

我已经使用它几个星期了,到目前为止我非常喜欢它。代码是可靠的,文档是一个很好的,非常合乎逻辑的构造,最终结果非常好。

我很喜欢与Hibernate结合使用来整理所有数据库乏味。

另外 - 易于部署  (使用Tomcat,您只需通过Web界面上传单个.WAR文件,就不会更容易了)

答案 8 :(得分:5)

在我们的公司,主要是一个大型Java SW房子(除其他外),我们有机会创建一个新的基于Web的产品。这是一组产品,并在三个国家有许多团队开发这个。当谈到我们的团队时,我可以选择使用Vaadin来利用我们的Java开发经验。我搜索了Google以帮助我做出决定。我也读过这篇文章;然而,我选择反对使用Vaadin,尽管许多其他球队选择了Vadin。以下是我在产品开始之前发送的邮件的原因(To Vaadin或Not)。这是我个人的看法,对框架的不信任总是在我身上不同程度。所以只想再向读者提出这个问题。

我们继续学习HTML,CSS,CSS选择器,精彩语言JavaScript和JS库,JQuery和YUI,并在完全GUI和性能合规的情况下及时创建了Web产品;我个人感到高兴,团队和用户一样好。

其他参加Vaadin方式的团队也及时创造了他们的产品,我猜也同样高兴。(只有他们不知道JavAScript他们缺少的快乐:))。

正如有人所说,所有抽象都是漏洞抽象,当他们不得不从Vaadin 6迁移到Vaadin 7时,他们不得不做一些重新工作,花费的时间比任何人都想象的要多;当然,他们设法磨砺和完善它;由于这个原因,还有一点延迟。我猜想InvientCharts插件存在一些问题,它不支持Vaadin 7导致团队购买($$)相关的Vaadin Charts插件并为此改变....

致Vaadin或不

使用Vaadin,似乎底层的JavaScript,HTML和CSS是从Java Swing类型的应用程序动态生成的。从一个偏见的,可能是愚蠢的纯粹主义的观点来看,这样的“我会为你生成代码”标语并没有给出好的设计气味。除非你需要抽象,否则为什么要绑定另一个框架。 与任何代码生成框架一样,它应该最适合Vaadin所考虑的抽象,但不是非常灵活; 我觉得,如果我们做网络技术,最好用技术引起的工具和语言 - 即HTML,CSS和JavaScript / JavaScript库,而不是依赖于另一层抽象 - Vaadin框架。对于专业的GWT或Vaadin开发人员来说,这可能会让我觉得天真,因为我猜Google编译器会产生比手动编码更优化的JavaScript,有助于在多个团队之间更好地管理代码等(但主要是在开发相当大的Web应用程序时),更好的开发人员生产力,更容易调试等 然而,在Java中为Vaadin编写组件,然后自动转换为JS,我感觉不对,我们的许多开发人员永远不会学习一种非常重要的编程语言 - 用于Web开发的JavaScript(并且在服务器端快速获得牵引力 - Node.js )。当依靠框架来使您的JavaScript正确时,您将永远不会使用该语言。我想对于一家以产品为基础的公司来说,重要的是要先学习网络语言。正如有人评论说,Java已经变得像是年度的COBOL,并且必须要有能力积累来学习其他重要的语言,比如JavaScript。 但是我已经在JS工作了很短的时间,我注意到如果我们用一些规则(模块模式)编写代码,测试所有逻辑--JavaScript单元--JSTestDriver,并运行JSHint,它是一个相当强大的语言来处理一旦学会了,生产力就会比Java好。  此外,大多数重要的组件示例 - OpenLayers都是用JS编写的,如果你需要扩展它们或者以最佳方式工作,你需要知道JavaScript,或者像D3.js那样强大的库。 简而言之,虽然使用Vaadin和框架有很多优势,但从长远来看,使用JavaScript很重要吗?

答案 9 :(得分:5)

我认为Wicket是前进的方向,直到我试图让它有效地工作并开始沮丧(笑话)。然后,我切换到GWT,看起来很棒,但是有太多的锅炉板代码要编写,文档也不是那么好...... - >光来自Vaadin:简单,可操作,到目前为止没有错误...... !!!

答案 10 :(得分:5)

同样值得考虑Apache Wicket作为面向组件的Java Web UI框架的强大替代方案。 Vaadin听起来不错,我不想贬低这种讨论,但选择是件好事。有一些关于源链接主页的例子,甚至还有更多关于WicketStuff网站的例子,Manning的优秀书籍构成了很棒的第三方文档。

答案 11 :(得分:5)

使用Maven查看Vaadin演示版本: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

答案 12 :(得分:3)

我也在使用Vaadin。虽然应用程序并不大,但我真正喜欢的经验是API是一致的,通常有很好的文档记录,并且考虑到我正在开发一个新工具,我能够为非常要求客户提供与我之前使用的工具相同或在某些情况下更好的时间框架。

很少有问题。现在唯一的一个就是客户坚持使用IE 7(不要问),并且一些看上去很棒的眼睛糖果在插件组件中不能完全100% (图表)。

顺便说一下,我也不为Vaadin工作: - )

答案 13 :(得分:2)

我已经尝试了Wicket和Vaadin,如果你真的尝试了一段时间,在一个月内你会知道Vaadin是要走的路,而不是Wicket,期间。 - Dheeraj G

答案 14 :(得分:2)

我们看过Wicket在哪里工作,但我们找到的不是9,000个文件,我们可以有超过30,000个。我们的核心金融服务应用程序有近1,000个屏幕,虽然Wicket看起来很棒,但将Struts 1.3代码转换为Wicket非常困难。我们的建筑师做了一个POC项目,只有3个屏幕增加了几百个类(许多是重复使用)。使用Wicket对屏幕进行原型设置也很困难,因为你的html必须与Java代码相匹配,反之亦然。

Vaadin看起来很有希望,但这对团队来说是一个很难卖的东西。

P.S。无论框架有多么伟大,如果没有在行业中使用,没有人会学习它。 Wicket已经存在了一段时间,但很少有公司使用它。与我交谈的大多数开发人员都关心学习一个在简历上无用的新框架。

关键是Vaadin使用类似Swing的设计,这有助于我使用Swing开始使用Java。

答案 15 :(得分:2)

我已经使用Vaadin在我工作的公司(而不是Vaadin;)开发了一个giftadvisor。

Vaadin允许您构建真正的组件化Swinglike Web应用程序。

如果您担心每次点击的客户端 - 服务器往返,我都会这样说:我创建了一个鼠标悬停按钮,可以改变按钮的外观,是的,鼠标悬停。为此,框架必须转到服务器并返回。它的工作速度足够快。请参阅http://www.cadeau.nl/sophie查看我的意思。

我喜欢Vaadin,它满足了我的需求,让网络开发变得轻而易举。

问候,Rob。

答案 16 :(得分:2)

我在两天前开始使用Vaadin,并且能够在OSGi上构建一个小型CRUD应用程序,其中包括模块化,数据绑定,OSGi服务以实现持久性。一个非常好的事情是我的完整UI只有118行代码,并支持简单的java bean结构的完整CRUD操作。

Vaadin在OSGi中的完美运作也很不错。它已经是一个捆绑包了,我找到了Neil Bartlet的一个小桥,它使得vaadin在OSGi中非常容易使用。

请参阅Tasklist Vaadin Example

答案 17 :(得分:1)

我不介意在服务器端使用状态。它有助于实现其目的。随着云计算现在的日常存储和带宽变得越来越便宜。但是,我可以从良好的设计角度看待你的观点,特别是如果你想要恢复你的应用程序。但我相信,关于Vaadin之类的东西,还有其他优点。一个主要的事情,你不必调整你的特定浏览器的web应用程序很多,我们称之为IE浏览器,因为Javascript / CSS错综复杂 - 特别是如果你像我一样面向后端。您的所有Web应用程序都可以在浏览器中兼容,而无需担心任何问题。请记住,开发人员的时间比存储和带宽贵。多数民论我的意见。 =)