企业应用程序是否使用 GWT [英] GWT or not for enterprise apps

问题描述

我正在开发一种在 app-engine 上创建企业级应用程序的工具.这需要跨浏览器(也包括IE8)，在移动设备上工作，稍后还通过(Qt4/GTK/etc)支持桌面客户端

I am working on an tool to create enterprise level applications on app-engine. This needs to be cross browser (also including IE8), works on mobile, and at a later point of time also supports desktop clients through (Qt4/GTK/etc)

我一直面临的问题是:对于我的网络应用程序 - 我应该使用 GWT(GoogleWebToolkit) 还是不使用?

The problem that I consistently face is this: For my web-application - should I use GWT(GoogleWebToolkit) or not?

我非常擅长使用EXT-JS"，但由于其开源政策，它不是一个选择.还有另一个框架SmartClient"，它有一个更好的开源许可证——它非常成熟，比 EXT-JS(基于一些 POC)更好，但它的文档很糟糕！我需要花费很多时间才能以正确的方式完成某件事.SmartClient 和 EXT-JS 非常适合企业级应用程序(如果使用得当) - 我在 Ext-JS 上经历过这种情况，并且对 SmartClient 也非常肯定.

I am pretty good at using "EXT-JS", but its not a choice due to its open-source policy. There is another framework "SmartClient" which has a better opensource license- Its pretty mature and better than EXT-JS (based on some POCs), but its documentation sucks! It takes me a lot of time to get something done in a right way. SmartClient and EXT-JS are pretty good for enterprise level applications (when used correctly) - I have experienced this with Ext-JS and very much sure on SmartClient too.

然后是JQuery 和插件以及 HTML5"的组合.与上述库相比，我喜欢更快、更干净、更小的 JS.我对 HTML5 持怀疑态度，因为这是一个不断发展的标准

Then there is this combination "JQuery and addons and HTML5". I love the faster, cleaner and smaller JS compared to the above libs. I am skeptical about HTML5 since thats an evolving standard

我真正喜欢 GWT 的是它的性能优势.至少这些例子似乎工作得很好.我不喜欢它的是 Java，而且我很擅长 javascript对于我在 app-engine 的服务器端应用程序，我使用的不是 Java，而是 Python.所以 rpc 将仅基于 json.我们目前还没有移动版本，但这又是以后非常需要的版本，我们以后可能会使用 Sencha-touch.

What I really like about GWT is its performance benefits. Atleast the examples seem to work great. What I dislike about it is Java and I am pretty good at javascript For my server-side-application at app-engine I am not using Java -but Python. so rpc would be based on json only. We do not have a mobile-version on the plate yet, but thats again a very much needed version later and we may use Sencha-touch for that later.

我已经为所有这些做了 POC，与 extjs 或 smartclient 相比，GWT 部署感觉快速和流畅.GWT 会自动为我做很多事情.我也喜欢 gwt 呈现的clean-html".我也很擅长使用 javascript，并且非常清楚在那里发生的导致 javascript 地狱的错误".

I have done POCs for all of these and GWT deployments feel fast and smooth compared to extjs or smartclient. And there is a lot of stuff that GWT does for me automatically. Also I love the "clean-html" rendered by gwt. I am pretty good at using javascript too and very well aware of the "mistakes" that happen there that lead to the javascript hell.

(我不期待 ExtGWT 或 SmartGWT)

(I am not looking forward to ExtGWT or SmartGWT)

关于我是否应该切换到 GWT 或者对于企业级应用程序来说这是一件好事有什么建议吗?

Any suggestions on whether I should switch to GWT or is it a good thing for enterprise level applications?

或者，如果有人使用 GWT 构建过大型应用程序，有什么缺点(和优点)?

Or if somebody has experienced building large apps using GWT, what were the cons (and pros)?

推荐答案

对于已经在 J​​SP/JEE 和 HTML/Javascript 方面有丰富经验的人来说，GWT 只需要半天时间就能理解.但是你需要两个月才能掌握.

For someone who already has extensive experience in JSP/JEE and HTML/Javascript, GWT would take only half a day to understand. But it will take you two months to master.

以下是我认为可以使您的企业级应用成功的技术与 GWT 相结合的建议.我认为您应该使用 GWT，因为它具有可调试性.但是可调试性是有代价的.GWT 调试至少需要一台四核 8GB 的​​机器.如果您认为这不正确，那可能是因为您找到了一种使 GWT UI 小而简单的方法.

Here is a recommendation of the combination of technologies with GWT that I believe would make your enterprise level apps successful. I think you should use GWT because of its debuggability. But debuggability comes at a price. GWT debugging requires at least a quad core 8GB machine. If you don't find this to be true, it's probably because you have found a way to make your GWT UI small and simple.

Eclipse 在调试 GWT 应用程序时挂起

RequiresResize、ProvidesResize 和 Layouts

在 GWT 中您需要掌握的第一件事是由接口 RequiresResize、ProvidesResize 规定的简单布局概念.您需要确保从 RootLayoutPanel 到可调整大小的小部件的 RequiresResize/ProvidesResize 链必须不间断.并且您需要掌握在 UI 中构建 RequiresResize/ProvidesResize 的流程.否则，当浏览器调整大小时，您会看到一两个奇怪的悬垂的果实伸出来无法调整大小.

The first thing you need to master in GWT is the simple concept of layouts that are dictated by the interfaces RequiresResize, ProvidesResize. You need to ensure the chain of RequiresResize/ProvidesResize from the RootLayoutPanel down to the resizable widgets must be unbroken. And you need to master architectecting the flow of RequiresResize/ProvidesResize in your UI. Otherwise, when the browser is resized, you would see one or two odd hanging fruits that stick out unresizable.

我认为应该不惜一切代价避免为每个小部件编写预定的调整器，而不是依赖于 Google 的 RequiresResize/ProvidesResize.否则，请记住在几次迭代中对调整大小进行去抖动.太多的尝试/错误让我无法完善调整大小.

I think writing scheduled resizers for every widget rather than depending on Google's RequiresResize/ProvidesResize should be avoided at all cost. Otherwise, remember to debounce the resize over a few iterations. Too much trial/error for me to perfect the resizing.

异步异步异步

您需要接受的下一个概念……我没有说您需要学习"，而是您需要接受"是 Javascript 的异步行为，因此也是 GWT Java 的异步行为.是否使用 GWT 并不重要.你必须习惯于将控制权倒置给被调用者来控制调用者的成功响应.

The next concept you need to accept ... I did not say "you need to learn", but "you need to accept" is async behaviour of Javascript and hence of GWT Java. It does not matter if you used GWT or not. You have to get used to inversion of control given to the callee to control the success response of the caller.

你不能写

List<Persons> persons = server.getData(personId);

你必须屈服于做事

server.getData(personId, new Callback<Persons>(){
  @override public void onSuccess(Person person){ ..... }
  @override public void onFailure(Exception ex){ ..... }
});

你不能写

boolean doOrNot = ConfirmDialogBox();

你必须写

ConfirmDialogBox(new CloseHandler(){
  public void onAccept(Person person){ ...}
  public void onCancel(){ ... }
});

GWT 是 Java 但不是 Java

我对不断尝试使用 apache 字节码 jars 与 GWT 客户端进行编译的人的不断存在感到好笑，GWT 客户端是用 Java 编写的 Javascript.

I am amused by the constant existence of people who keep trying to use apache bytecode jars to compile with the GWT client, GWT client is Javascript written in Java.

二进制数据和 GWT

GWT 视觉客户端

我发现的最佳组合是 GWT 2.4.0 和 Sencha gxt 2.2.5.

The best combination that I find is GWT 2.4.0 with Sencha gxt 2.2.5.

我避免使用 GXT-Uibinder 项目，因为我发现它对 3rd 方 GWT 框架的其他组合设置了不方便的限制.特别是那些严重依赖 GWT.create() 生成器的框架.GXT-Uibinder 是 Sencha 之外的项目.

I avoid using the GXT-Uibinder project because I find that it places inconvenient restrictions on other combinations of 3rd party GWT frameworks. Particularly those frameworks that depend heavily on GWT.create() generator. GXT-Uibinder is a project outside of Sencha.

GXT 2.2 及以下版本要求我编写包装器以使其可与 uibinder 一起使用，因为我拒绝使用 kludgy GXT-uibinder 项目.包装器是必要的，因为一个愚蠢的错位.任何在 uibinder 中用作父小部件节点的类都必须实现 GWT HasWidgets，这需要实现一个返回 iterator 的方法.不幸的是，GXT 2.2-- 已经实现了返回错误泛化迭代器的 iterator() 方法.

GXT 2.2 and below requires me to write wrappers to make it usable with uibinder, because of my refusal to use the kludgy GXT-uibinder project. Wrappers are necessary because of one silly misalignment. Any class used as a parent widget node in uibinder must implement GWT HasWidgets, which requires implementing a method returning iterator<Widget>. Unfortunately, GXT 2.2-- already implements the iterator() method that returns the wrong genericized iterator.

GXT 3 解决了这个问题.我认为 GXT 3 包含 GXT-uibinder，但您不必使用它.您不必使用 GXT 3(不使用 GXT-uibinder)编写太多包装即可与 uibinder 一起使用.但我发现 GXT 3 仍然有一些古怪的不当行为，试图解决这些怪癖不值得我花时间.所以我坚持使用 GXT 2.2.5，直到 GXT 3 稳定下来.

GXT 3 solves that problem. I think GXT 3 incorporates GXT-uibinder but you don't have to use it. You do not have to write much wrapping with GXT 3 (without using GXT-uibinder) to use it with uibinder. But I find that GXT 3 still has some quirky misbehaviour and trying to solve those quirks is just not worth my time. So I stick with GXT 2.2.5 until GXT 3 stabilises.

我创建了用于包装 SmartGWT 的 google 代码项目(uibinding-smartgwt).SmartGWT 是一个非常自私的框架.如果我尝试将它与 GWT 香草混合，我的努力通常会导致灾难.这是由于 SmartClient 和 GWT 的小部件之间存在某种 Z 索引.

I founded the google code project for wrapping SmartGWT (uibinding-smartgwt). SmartGWT is a very selfish fraemwork. My efforts often result in disaster if I try to mix it with GWT vanilla. It is due to some kinda of Z-indexing between the widgets of SmartClient and GWT.

如果您出于许可考虑而决定使用 SmartGWT，则必须确保仅使用 SmartGWT，而不是与任何其他小部件提供程序一起使用.甚至不是 GWT 香草.你很可能需要使用我的 uibinding-smartgwt 项目.我正在尝试增强它以使用一些较新的 uibinder 功能并重新定义非可视元素而不是小部件，但我目前对 GXT 的使用太过复杂，同时考虑这两个框架让我感到困惑.因为他们的行为不同.

If you decide to use SmartGWT due to licensing concerns, you have to makes sure you use only SmartGWT and not with any other Widget provider. Not even GWT vanilla. And you highly probably would need to use my uibinding-smartgwt project. I am trying to enhance it to use some newer uibinder features and redefine the non-visual elements not to be widgets, but my current use of GXT is simply too involved and thinking about the two frameworks at the same time confuses me. Because they behave differently.

尽管 GXT 3 似乎已经使自己与 GWT 完全一致，但 SmartGWT 并未表现出任何这样做的努力.3rd 方小部件提供程序与 GWT 之间的完全对齐，以便它顺利实现 GWT 的接口是绝对必要的，以避免浪费大量时间不得不编写一个又一个 kludge 来解决一些小的视觉问题.是的，尤其是 ProvidesResize/RequiresResize 架构.

Whereas GXT 3 seems to have made itself in complete alignment with GWT, SmartGWT has not demonstrated any effort to do so. Complete alignment between a 3rd party widget provider with GWT so that it implements GWT's interfaces smoothly is absolutely necessary to avoid wasting lots of time having to write kludges after kludges to solve some minor visual issues. Yes, especially the ProvidesResize/RequiresResize architecture.

永远不要使用 GWT 孵化.尝试它们，然后尝试使您的项目可维护、可持续和可增强.我们甚至不要去那里.

Don't ever use GWT incubation. Try them and then try to make your project maintainable, sustainable and enhanceable. Let's not even go there.

客户端-服务器通信

不要使用 GWT-RPC.不要.除了学习GWT的方便.

Do not use GWT-RPC. DO NOT. Except for the convenience of learning GWT.

RPC 适用于您无意扩展到演示阶段和几乎不可用阶段之外的简单应用程序.不编写分布式/分散式企业级应用程序的程序员可能不会同意我的观点.

RPC is good for simple apps whose role you have no intention of extending beyond the demo stage and barely usable stage. Programers who do not write distributed/sprawled out enterprise level apps probably would not agree with me.

单元测试对开发您的应用非常有帮助.首先忘记所有这些单元测试框架.能够编写一个简单的例程来测试每个小功能而不涉及应用程序的巨大图片是非常关键的.例如，我只想测试骆驼化循环以使其工作.GWT-RPC 给正式/非正式的单元测试带来极大的不便.

Unit testing is very helpful in developing your app. Forget about all those unit testing framework first. Just being able to write a simple routine to test each little feature without involving the huge gigantic picture of the app is very crucial. I just want to test that camelization loop to make it work, for example. GWT-RPC is an extreme inconvenience towards making your formal/informal unit testing.

我非常喜欢在 GWT 客户端使用 JAX-RS REST-RPC 通过 RestGWT 和在服务器端使用 RestEasy.我将 JAX-B 与 RestEasy 的 Jackson JSON 处理实现结合使用.您可以尝试使用 Jersey，而不是 Resteasy.

I am very attracted to using JAX-RS REST-RPC thro RestGWT on the GWT client side and RestEasy on the server side. I use JAX-B in conjunction with RestEasy's implementation of Jackson JSON processing. Instead of Resteasy, you could try using Jersey.

通过这种方式，我可以使用 FireFox REST 客户端来测试独立于 GWT 的服务器.事实上，在客户端使用 GWT 启动您的项目后，您可以扩展您的应用程序以使用非 GWT 客户端(如 JQuery)作为 REST 服务的客户端.

In this way, I could use FireFox REST client to test the server independent of GWT. In fact, after starting your project using GWT on the client-side, you could extend your app to use non-GWT clients like JQuery as clients to the REST services.

REST 还使您可以轻松编写代理/隧道服务器，让您克服浏览器的 SLD-SO-P(二级域，同源"策略)安全限制.鉴于 GWT-RPC 的数据格式是故意无法破译和不稳定的(我不明白谷歌工程师在这如何提高安全性背后的心态，因为你仍然可以看到人类可读文本的点点滴滴)，我没有尝试写隧道 GWT-RPC 服务的代理.我不知道它的可行性.

REST also makes it easy for you to write proxy/tunneling servers to let you overcome the SLD-SO-P ("2nd level domain, same origin" policy) security restrictions of browsers. Whereas, the data format of GWT-RPC is deliberately undecipherable and unstable (I don't understand the Google engineer's mentality behind how this increases security, since you could still see bits and pieces of human readable text), I have not attempted to write a proxy to tunnel GWT-RPC services. I don't know how viable it is.

http:///h2g2java.blessedgeek.com/2011/11/gwt-with-jax-rs-aka-rpcrest-part-0.html.

顺便说一句，克服 sld-sop 的脚本包含是一个非常糟糕的主意.想都别想.

BTW, script-include to overcome sld-sop is very bad idea. Don't even think about it.

坚持

用于非 GAE 的休眠 JPA.Eclipselink JPA for GAE with Google's MySQL用于 GAE 的 DataNucleus JPA，带有 Google 数据存储.

Hibernate JPA for non-GAE. Eclipselink JPA for GAE with Google's MySQL DataNucleus JPA for GAE with Google data store.

最初，我接受了 JDO 的想法.我很努力，JDO 总是给我冲突.我放弃.最初，Google 似乎一直在努力说服我们 JDO 是优越的 JPA.不管是真是假，到目前为止我还没有掌握使用JDO持久性的技巧.而且由于我也必须为非 GAE 编程，我不想让 JDO 的复杂性污染我的头脑.

Initially, I bought into the idea of JDO. I tried so hard, and JDO keeps giving me conflicts. I gave up. Initially Google appeared to have been trying hard to persuade us that JDO is superior JPA. Whether it is true or not, I have failed to acquire skills to using JDO persistence so far. And since I have to program for non-GAE too, I don't want to contaminate my mind with the complexity of JDO.

我提到这一点的原因是因为我倾向于使用与 JAX-RS POJO 相同的 JPA POJO.这意味着，我发现 JPA、JAX-RS、JAXB 和 Jackson 注释混合到同一个 POJO-DTO 中而没有冲突.我经常在 GWT 客户端、JAX_RS 服务器和 JPA 持久性之间共享一组 POJO(有一些例外).要实现这一点，您必须有一个限制——所有 DTO 都必须是 GWT 可序列化的.不仅仅是可序列化.尽可能避免编写 dto 转换器.浪费时间拥有三组不同的 POJO-DTO，然后在它们之间使用转换器.

The reason I mentioned this is because I tend to use the same JPA POJO with the JAX-RS POJO. Which means, I've found that JPA, JAX-RS, JAXB and Jackson annotation mix into the same POJO-DTO with no conflicts. I often have one set of POJOs (with some exceptions) shared between GWT client, JAX_RS server and JPA persistence. To achieve that, you have to have one restriction - all DTOs must be GWT-serializable. Not just serializable. Avoid writing dto converters as much as possible. Waste of time having three different sets of POJO-DTOs and then having converters between them.

MVP

我发现 MVP4G 是一个非常易于管理的 MVP 框架.以下讨论演示了我如何使用 MVP4G:

I find that MVP4G a very easy to manage MVP framework. The following discussion demonstrates how I use MVP4G:

https:///groups.google.com/forum/?fromgroups#!searchin/mvp4g/blessedgeek/mvp4g/T6r7egk-3Kk/Jz-dTqZDeMIJ

MVP 是一个非常有用的模式.因为它可以帮助我分离关注点".当您能够分离关注点时，您就能够单独测试和解决问题.它还可以帮助您增强/扩展您的项目，尽可能减少来自应用迷宫的其他问题/模块的干扰/纠缠.

MVP is a very helpful pattern. Because it helps me separate "concerns". When you are able to separate concerns, you are able to test and solve issues individually. It also helps you enhance/extend your project with as little interference/entanglement as possible from other concerns/modules of your labyrinth of applications.

MVP4G 还使单元测试变得容易，因为您可以简单地模拟视图或演示者，或者使用简化的事件总线/状态机仅调试您需要调试的那些部分.并且由于其模块化，您可以轻松避免非测试类的污染，这样您就可以在不破坏生产类的情况下删除测试源树.IOW，您不必修改非测试类来测试它们.

MVP4G also makes it easy to unit test, because you could simply mock a view or a presenter, or use a simplified eventbus/state-machine to debug only those parts you need to debug. And because of its modularity, you can easily avoid contamination of your non-test classes so that you could remove your test source trees without breaking your production classes. IOW, you don't have to modify your non-test classes to test them.

这篇关于企业应用程序是否使用 GWT的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！