GWT 与 Spring MVC 的比较
我想知道在这两种技术方面都有经验的人是否可以对两者进行客观的比较，假设您正在构建一个复杂的 Web 应用程序，该应用程序在服务器和浏览器中都非常丰富。
对我来说，旧范例的一个问题是 Spring MVC 层的可测试性。我发现由于无法测试的注释，许多错误可能会渗透到您的应用程序中。这种模型还会减慢开发周期，因为您必须重新启动服务器才能更改注释/控制器代码……我个人觉得这很烦人。
我也不想处理 javascript 的复杂性。使用 Java 来工作和测试应用程序听起来很吸引我。我真的不想掌握另一种语言，并学习它所有的怪癖、奇怪的设计决策、特质和浏览器不兼容的完整历史。
那么对于复杂的应用程序，GWT 会提供更好的方法吗？与 Spring MVC 相比，这种方法有什么严重的限制吗？ Spring MVC 可能更灵活，但更难使用？构建复杂应用程序时是否存在常见的陷阱和障碍？
我真的很感激两者之间的比较。请记住，我没有 GWT 经验，但有大约 10 年以上 Spring 经验。谢谢你！
I was wondering if someone who was experienced in both technologies could give an objective comparison between the two, assuming you were building a complex web application that would be both very rich in on the server and in the browser.
One problem with the older paradigm, for me, is testability of the Spring MVC layer. I find that there's a lot of bugs that can creep into your application due to untestable annotations. This model also slows development cycles because you have to restart the server to make changes to the annotations/controller code... which is something I personally find very annoying.
I also don't want to deal with the complexity of javascript. Working with and testing an application all in Java sounds appealing to me. I don't really want to master another language, and learn all of its quirks, weird design decisions, idiosyncracies and the full history of browser incompatibilities.
So for a complex application, would GWT offer a superior approach? Are there any serious limitations to this approach over Spring MVC, which would probably be more flexible although harder to work with? Are there any gotchas and road blocks that are common for building complex applications?
I would really appreciate a comparison between the two. Please keep in mind that I have no experience with GWT, but about 10+ years experience with Spring. Thank you!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
事实上，GWT 也有一个学习曲线，而且至少在我两年前查看它的时候，你对基本控件没有做太多事情，你需要外部库，这意味着更多的学习。
在尝试学习 GWT 但没有取得太大成功后，我选择了 Web 服务加上 jQuery 或 ExtJS，这也提供了非常清晰的角色分离。我坐下来学习了 JavaScript，这并不容易，但它比使用 GWT 有趣得多。
至于浏览器兼容性，一旦您使用现代库，您将拥有很少的浏览器兼容性。我的代码可以在所有浏览器中运行，没有太多问题，包括 IE 6。此外，当我太忙时，我只编写服务并外包 JavaScript 接口部分，这可以提高工作效率。
不管怎样，这是相当主观的，另一个精通 GWT 的人可能会有与我相反的观点。无论如何，我会拒绝以下理由：
据我现在所能想到的，唯一有效的理由是，我已经了解Java，我不想学习其他语言。
至于你对 Spring MVC 的评论。我正在使用Spring MVC，我不觉得重新启动服务器的痛苦。 Spring 的重点是一切都应该易于在容器之外使用！在 Spring 控制器中，我只有很少的代码来调用底层服务。我需要很好地进行单元测试的是服务。
控制器需要测试的代码很少，我可以直接调用它们并在 JUnit 中测试它们，但是，至少现在，我的方法是通过带有 jQuery 调用的网页完成简单的外部测试，以检查它们的响应（这不是单元测试，它是一个集成测试，但我觉得如果编写正确的话，对控制器进行单元测试的价值很小）。
The truth is that also GWT has a learning curve and also at least at the time I looked at it, two years ago, you're not doing much with the basic controls, you need external libraries and that means more learning.
After trying to learn GWT without much success, I opted for a webservice plus either jQuery or ExtJS, which also gives a very clean separation of the roles. I sat down and learnt JavaScript, it wasn't easy but it was immensely more fun than using GWT.
As for browser compatibility, once you use a modern library, you'll have very few of them. My code works in all browsers without too many problems, including IE 6. Also when I am too busy, I write the services only and outsource the JavaScript interface part, which allows increased productivity.
Anyway, this is fairly subjective, another person fluent with GWT, can have an opposite point of view of mine. I will anyway reject the following reasons:
As far as I can think now, the only valid reason is, I already know Java, I don't want to study another language.
As for your comment on Spring MVC. I am using Spring MVC and I don't feel the pain of restarting the server. The whole point of Spring is that everything should be easy to work with outside the container! In the Spring controllers I've very minimal code that just call the underlying services. What I need to unit test well are the services.
The controllers have very few code to test, I could just call them and test them within JUnit, but, at least for now, my approach is having a simple external test done through a web page with jQuery calls that check their response (it's not unit test, it's an integration test, but I feel there is a very little value to unit test a controller, if it's written properly).
我在一个复杂的项目中使用 GWT 已经一年多了（整个项目 200 KLOC），我建议您尝试一下 GWT。
在我看来，GWT 非常容易学习，有非常好的教程关于应该如何使用这项技术。
使用 GWT 的优点是，人们可以构建漂亮、快速、可维护的 Web 应用程序，而无需对浏览器或 JavaScript 了解甚少。您还可以使用 Java 调试器调试客户端代码，在复杂的应用程序中，这是巨大的。
尽管 GWT 提供了正确对客户端代码进行单元测试的可能性，但这需要对 GWT 的 MVP 范例有很好的理解并进行仔细的规划。如果你搞乱了你的代码（这并不难，因为 GWT 给了你完全的自由），那么你最终会失去这个功能，但这是你的错，而不是 GWT 的错。
I am using GWT for more than a year now in a complex project (200 KLOC for the whole project), and I recommend you to give GWT a try.
In my opinion GWT is quite easy to learn, there are really good tutorials about how one should use this technology.
The advantage of using GWT is that one can build nice, fast, maintainable web apps, without knowing very little about browsers or javascript. You can also debug your client side code with a Java debugger and in complex apps this is huge.
Although GWT offers the possibility to properly unit test the client side code, this requires a good understanding of GWT's MVP paradigm and careful planning. If you mess up your code (which is not that hard, because GWT gives you total freedom) then you are going to end up losing this feature, but this is your fault, not GWT's.
我花了几个月的时间才很好地学习 Spring 来创建相当基本的 MVC 应用程序。我花了大约一个月的时间才掌握了 GWT。 （可能它更容易，因为我已经使用 Android 三年了，而且它的工作原理类似。它甚至对一些问题有完全相同的不明显的解决方案。）所以对我来说，GWT 绝对比春天。
It took me a couple of months to learn Spring well enough to create fairly basice MVC apps. It took me about a month to master GWT. (It could be that it was easier because I had already worked with Android for three years and it works similar. It even has the exact same unobvious solutions to some of its problems.) So for me, GWT was definitely much easier to learn than Spring.