您对构建 GWT 应用程序有何建议？ MVC、MVP 还是自定义消息传递解决方案？
我刚刚为客户启动了一个新的 GWT 项目，我有兴趣听取人们对各种 GWT MVC 架构的体验。 在最近的一个项目中，我使用了 GXT MVC 以及自定义消息传递解决方案（基于Appcelerator 的 MQ）。 GXT MVC 工作正常，但对于 GWT 来说似乎有点大材小用，并且很难与浏览器历史记录一起使用。 我听说过 PureMVC 和 GWTiger，但从未使用过它们。 我们的自定义 MQ 解决方案运行得很好，但很难使用 JUnit 测试组件。
此外，我听说 Google Wave（一个 GWT 应用程序）是使用模型-视图-呈现器模式编写的。 最近发布了示例 MVP 应用，但查看代码，它并没有看起来没那么直观。
如果您要构建新的 GWT 应用程序，您会使用哪种架构？ 您的选择有哪些优点和缺点？
谢谢，
马特
I just started a new GWT project for a client and I'm interested in hearing people's experience with various GWT MVC architectures. On a recent project, I used both GXT MVC, as well as a custom messaging solution (based on Appcelerator's MQ). GXT MVC worked OK, but it seemed like overkill for GWT and was hard to make work with browser history. I've heard of PureMVC and GWTiger, but never used them. Our custom MQ solution worked pretty well, but made it difficult to test components with JUnit.
In addition, I've heard that Google Wave (a GWT application) is written using a Model-View-Presenter pattern. A sample MVP application was recently published, but looking at the code, it doesn't seem that intuitive.
If you were building a new GWT application, which architecture would you use? What are the pros and cons of your choice?
Thanks,
Matt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
值得注意的是，google终于写出了使用mvp架构进行设计的教程。 它澄清了上面列出的 google i/o 演讲中的许多内容。 看一下：https://developers.google.com/web-toolkit/articles /mvp-架构
It's worth noting that google has finally written out a tutorial for designing using the mvp architecture. It clarifies a lot of the elements from the google i/o talk listed above. Take a looK: https://developers.google.com/web-toolkit/articles/mvp-architecture
我很高兴有人问这个问题，因为 GWT 迫切需要一种类似 Rails 的方式来构建应用程序。 一种基于最佳实践的简单方法，适用于 90% 的所有用例，并实现超级简单的可测试性。
在过去的几年里，我一直以一种非常被动的方式使用我自己的 MVP 实现，这种观点使自己受制于 Presenter 告诉他做的任何事情。
我的解决方案包括以下内容：
视图获取对演示者的引用作为其构造函数参数，因此它们可以使用演示者初始化其事件。 演示者将处理这些事件并通知其他小部件/视图和/或调用 gwt-rpc，成功后将其结果放入模型中。 该模型具有典型的“Property [List [String]]名称= ....”属性更改侦听器机制，该机制向演示者注册，以便gwt-rpc请求对模型的更新会发送到所有视图/小部件感兴趣。
通过这种方法，我使用 EasyMock 为我的 AsynInterfaces 获得了非常简单的可测试性。 我还能够轻松地交换视图/小部件的实现，因为我必须重写的只是通知演示者某些事件的代码 - 无论底层小部件（按钮、链接等）如何。
我的方法存在的问题：
我对这些问题的解决方案：
总结：
我不认为有一个可以对整个应用程序使用单一“MVP”方法。 人们肯定需要应用程序导航的历史记录、像 GXT-MVC 这样的事件总线来附加/分离屏幕，以及 MVP 来轻松测试小部件的数据访问。
因此，我提出了一种结合这三个要素的分层方法，因为我相信“单事件 MVP 系统”解决方案行不通。 导航/屏幕附加/数据访问是三个独立的问题，我将在接下来的几个月中重构我的应用程序（迁移到 GXT），以便分别针对每个问题使用所有三个事件框架（这项工作的最佳工具）。 所有三个元素不需要互相了解。 我确实知道我的解决方案仅适用于 GXT 项目。
当编写大型GWT应用程序时，我觉得我必须在客户端重新发明像Spring-MVC这样的东西，这真的很糟糕，因为需要花费大量的时间和脑力才能吐出像Spring MVC这样优雅的东西。 GWT 更需要一个应用程序框架，而不仅仅是编译器人员辛勤工作的那些微小的 JS 优化。
I am glad this question has been asked, because GWT desperatley needs a rails-like way of structuring an application. A simple approach based on best practices that will work for 90 % of all use-cases and enables super easy testability.
In the past years I have been using my own implementation of MVP with a very passive view that enslaves itself to whatever the Presenter tells him to do.
My solution consisted of the following:
The Views get a reference to the presenter as their constructor parameter, so they can initialize their events with the presenter. The presenter will handles those events and notify other widgets/views and or call gwt-rpc that on success puts its result into the model. The model has a typical "Property[List[String]] names = ...." property change listener mechanism that is registered with the presenter so that the update of a model by an gwt-rpc request goes to all views/widgets that are interested.
With this appraoch I have gotten very easy testability with EasyMock for my AsynInterfaces. I also got the ability to easily exchange the implementation of a view/widget, because all I had to rewrite was the code that notified the presenter of some event - regardless of the underlying widget (Button, Links, etc).
Problems with my approach:
My Solutions to those problems:
Summary:
I dont think one can use a single "MVP" approach for an entire app. One definetly needs history for app-navigation, a eventbus like GXT-MVC to attach/detach screens, and MVP to enable easy testing of data access for widgets.
I therefore propose a layered approach that combines these three elements, since I believe that the "one-event-mvp-system"-solution wont work. Navigation/Screen-Attaching/Data-Access are three separate concerns and I will refactor my app (move to GXT) in the following months to utilize all three event-frameworks for each concerns separately (best tool for the job). All three elements need not be aware of each other. I do know that my solution only applies for GXT-projects.
When writing big GWT apps, I feel like I have to reinvent something like Spring-MVC on the client, which really sucks, because it takes a lot of time and brain-power to spit out something elegant as Spring MVC. GWT needs an app framework much more than those tiny little JS-optimizations that the compiler-guys work so hard on.
以下是最近关于构建 GWT 应用程序的 Google IO 演示。
享受。
-J.P
Here is a recent Google IO presentation on architecting your GWT application.
Enjoy.
-JP
如果您对使用 MVP 架构感兴趣，您可能需要查看 GWTP： http://code.google.com/p/gwt-platform/。 这是我正在开发的一个开源 MVP 框架，它支持 GWT 的许多优秀功能，包括代码分割和历史管理，以及一个简单的基于注释的 API。 它是最近才出现的，但已经在许多项目中使用。
If you're interested in using the MVP architecture, you might want to take a look at GWTP: http://code.google.com/p/gwt-platform/ . It's an open source MVP framework I'm working on, that supports many nice features of GWT, including code splitting and history management, with a simple annotation-based API. It is quite recent, but is already being used in a number of projects.
您应该查看 GWT Portlet。 我们在开发大型 HR 门户应用程序时开发了 GWT Portlet 框架，现在它是免费且开源的。 来自 GWT Portlets 网站（托管在 Google 代码上）：
编程模型有点类似于为门户服务器（Liferay、JBoss Portal 等）编写 JSR168 portlet。 “门户”是使用 GWT Portlets 框架作为库构建的应用程序。 应用程序功能被开发为松散耦合的 Portlet，每个 Portlet 都有一个可选的服务器端 DataProvider。
每个 Portlet 都知道如何将其状态外部化为可序列化的 PortletFactory 子类（momento / DTO / 工厂模式），从而使重要功能成为可能：
列出了该框架的其他重要功能如下：
GWT Portlet 用 Java 代码实现，不包装任何外部 Javascript 库。 它不强加任何服务器端框架（例如 Spring 或 J2EE），但设计为与此类框架配合良好。
You should have a look at GWT Portlets. We developed the GWT Portlets Framework while working on a large HR Portal application and it is now free and open source. From the GWT Portlets website (hosted on Google code):
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
Every Portlet knows how to externalize its state into a serializable PortletFactory subclass (momento / DTO / factory pattern) making important functionality possible:
Other important features of the framework are listed below:
GWT Portlets is implemented in Java code and does not wrap any external Javascript libraries. It does not impose any server side framework (e.g. Spring or J2EE) but is designed to work well in conjunction with such frameworks.