GWT或不适用于企业应用程序 [英] GWT or not for enterprise apps
问题描述
我正在开发一种在应用引擎上创建企业级应用的工具。这需要是跨浏览器（也包括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)
我一直面对的问题是这样的：对于我的Web应用程序 - 我应该使用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。与以上的lib相比，我喜欢更快，更干净，更小的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 -but 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.
我已经完成了所有这些和GWT部署的POC，与extjs或smartclient相比，速度和流畅性都比较快。 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)?
推荐答案
p>对于已经在JSP / 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.
RequiresResize，ProvideResize和Layouts
您需要在GWT中掌握的第一件事是简单的布局概念这是由RequiresResize，ProvideResize接口决定的。您需要确保RootLayoutPanel中的RequiresResize / ProvideResize链，直到可调整的小部件必须是不间断的。并且您需要掌握在UI中构建RequiresResize / ProvideResize的流程。否则，当浏览器调整大小时，您会看到一两个奇怪的悬挂水果，突出显示不可定义。
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 / ProvideResize。否则，请记住在几次迭代中反弹调整大小。太多的试用/错误让我完成了调整大小。
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字节码jar来编译GWT客户端的人不断的存在感到欣慰，GWT客户端是用Java编写的。
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 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项目，因为我发现它对第三方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< Widget> 的方法。不幸的是，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（uibinding-smartgwt）的google代码项目。 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，而不与任何其他Widget提供商一起使用。甚至没有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没有表现出任何努力。第三方窗口小部件提供者与GWT之间的完全对齐，以便平滑地实现GWT的界面是绝对必要的，以避免浪费大量时间在kludges之后写入kludges以解决一些小的视觉问题。是的，特别是ProvideResize / 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.
我非常喜欢使用JAX-RS REST-RPC thro RestGWT 在GWT客户端，服务器端的 RestEasy 。我使用JAX-B结合RestEasy实现的杰克逊JSON处理。而不是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的数据格式故意不可破译和不稳定（我不明白Google工程师的心态背后如何增加安全性，因为您仍然可以看到可读文本的一些部分），我没有尝试写代理隧道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 。
BTW，脚本包括克服sld-sop是非常糟糕的主意。甚至没有想到它。
BTW, script-include to overcome sld-sop is very bad idea. Don't even think about it.
持久性
Hibernate JPA for non -GAE。
用于Google的MySQL
的Eclipselink JPA与Google数据存储的GAE的DataNucleus JPA。
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中，没有冲突。我经常有一组POJO（有一些例外）在GWT客户端，JAX_RS服务器和JPA持久性之间共享。要实现这一点，您必须有一个限制 - 所有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:
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屋！
