我只是尝试使用Vaadin Framework,在我看来它很容易使用.此外,我喜欢他的框架是它建立在Google Web Toolkit(GWT)之上.
你怎么想,我应该继续使用这个框架,还是最好坚持使用GWT？
嘿.作为免责声明,我为开发Vaadin的公司工作.
Vaadin以一种在GWT中预编译的一组组件的方式使用GWT.当然,如果您愿意,您还可以另外制作自己的组件.但是,这组组件非常完整,通常可以根据您的需要进行定制.这意味着每次更改应用程序时都不必将代码从Java重新编译为JavaScript.您只需将已有的组件组合在一起.
该框架是服务器驱动的,因此所有逻辑都在服务器端处理.组件有两部分,客户端和服务器文件.客户端只是组件的虚拟"视图".一旦你与它交互,它就会向服务器发送一条消息,告知这个或那个被按下/写入/等等.然后服务器决定应该做什么.这是为了提高安全性,因为您不能"破解"逻辑,因为在javascript中只有用于发送请求的小API.在某些情况下,这可能与应用程序的速度有一点权衡,但我不认为它是如此糟糕.最糟糕的速度颠簸通常是数据库查询往返等,这与UI框架的选择没有任何关系.所建议的演示的低迷可能是因为你离服务器很远或者目前用户受到很大的打击.在自己的环境中尝试,关闭应用程序的最终应用程序,看看它的执行情况.您可以部署一些现成的应用程序来测试它.
我想这个选择归结为你想要做的事情.Vaadin适用于Web应用程序,因为您可以轻松构建普通的Java应用程序并为其创建动态Web UI.如果您在传统网站上做更多事情,用户只能查看页面 - 而不是主动与之交互,那么Vaadin不是最好的方式.与其他一些免费框架(如rails或php框架等)一起使用.我认为你正在做一个应用程序,因为你建议你现在正在使用GWT,所以Vaadin应该是好的.
在这里,在Vaadin论坛或者irc频道#vaadin @freenode上提出更多问题,也许有人可以给你更多理由为什么或为什么不使用Vaadin.
经过近一年的时间开发一个不那么庞大的GWT应用程序,使用我从上一个Google I/O中学到的所有最佳实践,如MVP,EventBus,CommandPattern等.我从内心深处说出这一点:经过几天的努力为了让我的团队和客户在技术上和视觉上都想要的方式工作,即使在UiBinder发布之后,Vaadin就像隧道尽头的灯光一样来到我身边.
在为命令模式编写了将近一千个样板操作,另外一千个演示者和视图以及另外一千个事件处理程序等之后.不必处理这些类中的近75%并且仍然保持良好的模式方法(appfoundation add-on),一点网络开销是可以接受的.使用Vaadin,开箱即用,您可以获得良好的小部件,分页,数据绑定,完美的布局.这一切都是为了什么？服务器端的内存消耗量更多.
我想我可以说这是可以接受的,因为我没有建立下一个Facebook或其他东西.我仍然可以为每台中型服务器处理数千个并发用户,同时保持低延迟往返.
使用Vaadin,我可以使用几乎一半的代码行构建一个不错的应用程序,但应用程序似乎仍然更完整.:-)
!更新2011年2月23日:我无法强调应该如何了解每个框架的局限性.Vaadin也不例外.应该知道Vaadin抽象出任何形式的HTML或JavaScript.此外,生成的HTML非常繁重,您应该自己处理历史状态更改.因此,在构建项目时要注意这些开销.
免责声明:我与以后提到的图书馆没有任何联系,但碰巧知道我的方式很好.
和你一样,在考虑用于新项目的堆栈/框架时,我偶然发现了这篇文章.我对Play有一些扎实的经验!(好吧,在Scala中,但这不相关)但是引人注目的小部件及其与服务器端的无缝集成+ Swing就像开发一样激起了我的兴趣.那是在2010年末,当答案说服我试试Vaadin时,我决定回来写下我想在这里读到的答案,特别是.因为这个问题今天仍然有用.与此同时,Vaadin从第6版到第7版,只需要一些显着的改进,Play!从版本1到2,我(+一个小团队)用两个框架完成了少量成功的项目.
我认为比较有趣,因为两个框架
在JVM上运行,可以利用其丰富的生态系统
在他们的Web应用程序方法和你作为开发人员应该关心的内容方面,并没有更多的分歧
在较小程度上,它们与Java EE的关系.
赞美
在一句话中,如果您发现将桌面应用程序移植到浏览器同时完全从底层HTTP请求/响应机制中抽象出来的想法,那么Vaadin可能是您制作Web应用程序的候选者.对于那些最喜欢HTML和JavaScript低级别的人来说,它的Swing编程方法可以轻而易举.对您的应用程序的新请求确实正在启动一个新实例,其余的流程由您和您的逻辑决定.链接恢复到良好的旧按钮导航,您可以使用许多内置模板自由组合您的布局,而无需调整HTML或CSS.API通常是非常一致的,并且公认有很好的文档(Vaadin书是强制性阅读.尽管很多东西都很容易获得,例如将bean绑定到组件和验证器,......).这些小部件具有良好的整体跨浏览器兼容性,从而确保应用程序在各种客户端上的一致行为.
现实检查
我们在开发和测试我们的Vaadin应用程序时度过了愉快的时光.当我们发布第一个版本并开始收集反馈时,事情变得更加清晰和细致.我们意识到我们实际上已经在一些基本方面存在偏见,即:
在201x年代,大多数用户使用网络的历史悠久,其中很少有人实际上不再使用桌面应用程序.这里的关键点是浏览器使用超文本链接标准化UX交互,后退,前进和重新加载按钮,无处不在的选项卡和有时窗口,以及大多数操作触发HTTP请求并等待响应的基本思想.这是网站所依赖的隐含合同.因此,当用户抱怨他们不能像以前那样使用后退/前进按钮,或者标签不按预期方式工作时,我们不应该感到惊讶.我们同意了.我们打破了隐形合约绑定用户和浏览器.实际上,我们自己隐含地没有像我们在任何其他网站上一样使用我们的浏览器和Vaadin应用程序.当然,您可以回到前面提到的书籍并仔细阅读使用URL片段复制Web导航体验,您会发现它实际上比预期更多,因为Vaadin应用程序是有状态的.而且,与Play相比,MVC或MVP范例只是松散地强加给了开发人员!几乎没有其他选择.不要掉以轻心,但是在页面更改后,你的大脑会被用于亮白屏幕,只需几秒钟.当用户点击并希望获得新页面时,浏览器会通过显示沙漏(或其变体)来确认.使用AJAX,请求被置于幕后.今天有些小型,几乎是外科手术的AJAX罢工已成为常态,但尚未针对主要的UI更新.
有状态的应用程序带来了他们的挑战......和麻烦.负载平衡(如果您担心)一个更复杂.事务的概念完全不同,因为Vaadin会话跨越了许多请求,因此与基于REST的方法形成鲜明对比,但在UX方面却相对较短.实际上,用户回到他们几小时前开始完成任务的表格并不少见.从理论上讲,这也可以与Vaadin一起工作,但你必须长时间保持会话存活,内存一直被阻塞,并仔细考虑这将会影响并发用户.
有状态页面也很难让用户共享,更不用说书签了(假设您处理了URL片段).
最后,我们分享了这样的印象:UI通常在服务器上的逻辑上更加迟钝.当然,您可能总是创建一个装有客户端JavaScript的小部件来减少往返次数,但您不可避免地必须在服务器上进行一些UI更新.JS在我的体验中已经非常沉重,并且在移动设备上的体验较少(我知道TouchKit,但仍然是:移动设备上的HTML5应用程序并没有为我剪掉它).另外,请记住,在发布请求后UI线程处于活动状态(即客户端的用户操作,类似于拉动UI更新),并且您可以通过各种侦听器访问它.但是,从后台线程更新UI更复杂(例如,推送更新).Vaadin 7改善了这方面的情况,特别是在生成相对较轻的HTML时.通过简单地打开HTTP压缩,可以明显改善UI反应性.
结论
所以我们停下来想知道我们在Vaadin方法中发现了什么如此有吸引力.最初的开发是一个相对平稳的过程,产生了快速的结果,但重新设计一些概念以适应Web用户体验的期望给了我们一个强烈的游泳逆潮流的印象.我们的结论是,从HTTP请求/响应机制中抽象(模糊？)的诱惑理念被证明是一把双刃剑,揭示了Web应用程序和桌面应用程序之间的真正阻抗不匹配.
我们强烈认为应该采用它的工作方式而不是假装网络是另一层,而是从拥有以URL为中心的应用程序(由Rails/Django/Play强加)开始.你可能听说有人说数据比应用程序更长.现在,数据由URL资源引用,因此可以安全地说URL比数据更长.毕竟,他们是人们的书签,不是吗？因此,基本的关注点分离也应适用于此级别.这可能就是为什么网络首先变得如此受欢迎的原因.因此,我们重新审视我们的应用程序构建更围绕一个中心控制器响应行动点菜播放的不同的资源路径做.
目前我们正在维护我们的Vaadin应用程序,但由于其中一些限制和基本范式的转变,我们不会用它开始新的项目.然而,对于团队来说,他们建立了一个技术上连贯,有凝聚力且记录完备的360°Java Web框架,需要对Web内部工作知之甚少.从好的方面来说,他们甚至还通过销售咨询服务的公司支持他们的框架.我很感激这次经历以及它如何重新评估我对网络应用程序的看法.我将密切关注它的发展,但我们肯定需要更多的控制和粒度.
希望有一天Vaadin会从整个Servlet架构中解脱出来,它依赖于它拥有自己的HTTP服务器.更好的是MVC设计更深植于框架中.但在可预见的未来,这似乎有点不太可能,因为它似乎在经验丰富的企业Java大猩猩中找到了一个利润丰厚的利基,他们只是发誓EE.闪耀.
TL; DR:我认为Vaadin忽略了Webapps的重点,更重要的是,他们应该如何表现.这是程序员接受网络以及用户如何与之交互的时间(即后退按钮,重新加载按钮,标签和书签).Web应用程序越接近HTTP请求和语义(动词),就越有可能匹配用户期望.这是关键.
编辑:如果您有任何Python经验,我强烈建议您尝试使用Flask来获得以网址为中心,基于REST的Web应用程序编程.
编辑2:如果由于任何原因你觉得你必须使用全栈Vaadin框架,那么试试Meteor吧.它是一个基于JavaScript的(前端和后端)框架,在Node.js上运行,通过WebSocket进行异步通信(因此延迟比请求/响应小),默认情况下它是被动的.在流星中已经解决了我在Vaadin中不喜欢的一些事情.例如,UI更新的逻辑在客户端上运行,这使得它比Vaadin更具响应性.JavaScript和Java社区中的人们并没有多少交叉,但是当我第一次听到它时,与Vaadin的并行立刻让我感到震惊.它目前在社区中享有相当多的动力,其原因类似于使Vaadin流行的原因,即.能够制作类似桌面的Web应用程序.如果您也意识到Java在未来的Web应用程序中并不存在太大的影响,或者如果您厌倦了那些长时间的部署周期,那么就应该试一试.但在将整个应用程序绑定到一个库之前要三思而后行.
关于Vaadin的通常谈论涉及小部件集和担心客户端和服务器之间的往返通信.
但在我看来,这忽略了Vaadin最重要的(也许是革命性的)方面:它完全消除了设计和实现AJAX应用程序通常需要的客户端 - 服务器通信的任务(AJAX中的"A"和"X") .
使用Vaadin,您可以完全忘记DTO(数据传输对象),基于协议的安全问题,Hibernate延迟加载异常等.
从某种意义上说,只是编写一个常规的旧Java Swing桌面应用程序,只有您使用的是Swing中不同的UI工具包.
根据我的经验,GWT需要很多样板代码,并且在构建复杂且丰富的UI时会变慢.通常我们处理包含许多可持久域对象的非常复杂的应用程序模型.要将所有这些数据带到客户端,您需要引入单独的客户端模型并提供数据转换机制.我们为此目的使用了Dozer,它需要花费很多时间来映射每个字段,创建自定义转换器并测试所有这些东西.
另一方面,如果不进入过度工程,如果应用程序不是很复杂,您可能会利用客户端资源并减少服务器负载.通过这种方式,您可以极大地减少与服务器的通信,并获得更具响应性的软件.
Vadin看起来非常开发人员:)但我有点害怕对服务器的"大规模AJAX攻击".我有ZK的经验,并且当UI上的一个简单操作工作缓慢因为它需要与服务器通信时,我们经常遇到性能问题.
Wicket是另一个很好的框架,但它更适合网站.它可以使用和不使用AJAX,可以被搜索引擎索引.最有吸引力的是它处理干净的HTML代码 - 没有自定义标签,没有控制结构,严格的关注点分离和组件的特定wicketid namigs.
这主要取决于您的需求:
如果您需要超快速且简单的应用程序 - 使用GWT并利用客户端资源
如果您的应用程序非常复杂,那么Vaadin看起来是更好的选择
如果您的应用程序是公开的,并且您需要能够为SEO编制索引而不是选择Wicket.
事情是,对于认真的发展,你不能忘记任何事情,更不用说dtos ..我正在抛弃缝,服务器端ui概念只是因为我希望更好地控制电线上的内容.. vaadin对我的问题正是这一点,在服务器端有状态..
关于Wicket使用会话来管理组件状态和可伸缩性存在"关注点",类似于关于Vaadin和服务器端处理的论点.在过去的十年中,我了解到Java社区在如何衡量Web框架的潜力(以及其他方面)方面通常是错误的.从JSF到Grails,它通常需要几百GB的内存和至少十二个具有重叠和低效功能的开源jar文件才能运行生产应用程序.环顾四周,您将看到大多数Web托管公司都没有提供实用的Java选项,因为Java技术为Web框架采用了不稳定的路径.由于编译速度的原因,GWT 2.1仍然很难使用,而且从一开始就应该有MVP和数据表.我喜欢Wicket,但是Vaadin看起来很有希望...但是知道Java框架是如何发展的,我相信他们会在某些时候开始自我攻击,但我怀疑是因为服务器端处理繁重.
为了构建外观漂亮的用户界面,我想说这将是最佳选择.此外,它有很好的记录.
我已经使用了几个星期,到目前为止我真的很喜欢它.代码是扎实的,docs很好,非常合乎逻辑的构造,最终的结果非常好.
我喜欢它与Hibernate结合使用来整理所有的数据库乏味.
另外 - 易于部署(使用Tomcat,您只需通过Web界面上传单个.WAR文件,就不容易了)
同样值得考虑Apache Wicket作为面向组件的Java Web UI框架的强大替代品.Vaadin听起来不错,我不想贬低这种讨论,但选择是件好事.有一些关于源链接主页的例子,甚至还有更多关于WicketStuff网站的例子,Manning的优秀书籍构成了很棒的第三方文档.
使用Maven查看Vaadin演示版本:http: //asolntsev.blogspot.com/2009/11/vaadin-demo.html
我认为Wicket是前进的方向,直到我试图让它有效地工作并开始沮丧(笑话).然后,我切换到GWT,看起来很棒,但是有太多的锅炉板代码要写,文档也不那么好...... - >来自Vaadin的光:简单,可操作,到目前为止没有错误...... !
在我们的公司,主要是一个大型Java SW房子(除其他外),我们有机会创建一个新的基于Web的产品.它是一组产品,并在三个国家有许多团队开发这个.当谈到我们的团队时,我可以选择使用Vaadin来利用我们的Java开发经验.我搜索了Google以帮助我做出决定.我也读过这篇文章; 然而,我选择反对使用Vaadin,尽管许多其他球队选择了Vadin.以下是我在产品开始之前发送的邮件的原因(To Vaadin或Not).这是我个人的看法,对框架的不信任总是在我身上不同程度.所以只想再向读者提出这个问题.
好吧,我们继续学习HTML,CSS,CSS选择器,精彩语言JavaScript和JS库,JQuery和YUI,并及时创建了Web产品,具有完整的GUI和性能; 而我个人感到高兴,团队和用户一样好.
其他采用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可能很重要吗？
京公网安备 11010802040832号 | 京ICP备19059560号-6 