您对构建 GWT 应用程序有何建议？MVC、MVP 还是自定义消息传递解决方案？

Question

我刚刚为客户启动了一个新的 GWT 项目，我有兴趣听取人们对各种 GWT MVC 架构的体验。在最近的一个项目中，我同时使用了 GXT MVC, ，以及自定义消息传递解决方案（基于 Appcelerator 的 MQ）。GXT MVC 工作正常，但对于 GWT 来说似乎有点大材小用，并且很难与浏览器历史记录一起使用。我听说过 纯MVC 和 GW虎, ，但从未使用过它们。我们的自定义 MQ 解决方案运行得很好，但很难使用 JUnit 测试组件。

此外，我听说 Google Wave（一个 GWT 应用程序）是使用模型-视图-呈现器模式编写的。A 示例 MVP 应用程序 最近发布了，但是看代码，似乎不太直观。

如果您要构建新的 GWT 应用程序，您会使用哪种架构？您的选择有哪些优点和缺点？

谢谢，

马特

Answer 1

这是值得注意的是，谷歌终于写出了一个教程使用MVP的架构设计。它澄清很多来自谷歌I / O谈话上面列出的元素。一起来看看： https://developers.google.com/web-toolkit/articles / MVP-架构

Answer 2

我很高兴有人问这个问题，因为 GWT 迫切需要一种类似 Rails 的方式来构建应用程序。一种基于最佳实践的简单方法，适用于 90% 的所有用例，并实现超级简单的可测试性。

在过去的几年里，我一直以一种非常被动的方式使用我自己的 MVP 实现，这种观点使自己受制于 Presenter 告诉他做的任何事情。

我的解决方案包括以下内容：

• 每个小部件的接口定义控制视觉外观的方法
• 一个实现类，可以是 Composite 或使用外部小部件库
• 一个屏幕的中央演示器，该屏幕托管由 M 个小部件组成的 N 个视图
• 每个屏幕的中央模型保存与当前视觉外观相关的数据
• 通用侦听器类，如“SourcesAddEvents[CustomerDTO]”（编辑器不喜欢这里的 java 泛型的真实符号，因此我使用括号），因为否则您将拥有许多相同的接口，只是类型有所不同

视图获取对演示者的引用作为其构造函数参数，因此它们可以使用演示者初始化其事件。演示者将处理这些事件并通知其他小部件/视图和/或调用 gwt-rpc，成功后将其结果放入模型中。该模型具有典型的“Property [List [String]]名称= ....”属性更改侦听器机制，该机制向演示者注册，以便gwt-rpc请求对模型的更新会发送到所有视图/小部件感兴趣。

通过这种方法，我使用 EasyMock 为我的 AsynInterfaces 获得了非常简单的可测试性。我还能够轻松地交换视图/小部件的实现，因为我必须重写的只是通知演示者某些事件的代码 - 无论底层小部件（按钮、链接等）如何。

我的方法存在问题：

• 我当前的实现使得很难在不同屏幕的中央模型之间同步数据值。假设您有一个显示一组类别的屏幕和另一个允许您添加/编辑这些项目的屏幕。目前，跨屏幕边界传播这些更改事件非常困难，因为这些值被缓存在这些模型中，并且很难找到我们是否有些东西是脏的（在传统的 web1.0-html 中很容易） -dumb-terminal 是一种带有服务器端声明性缓存的场景）。
• 视图的构造函数参数可以实现超级简单的测试，但是如果没有可靠的依赖注入框架，“onModuleLoad()”中就会有一些丑陋的工厂/设置代码。当我开始这个的时候，我不知道 Google GIN，所以当我重构我的应用程序时，我将使用它来摆脱这个样板。一个有趣的例子是 GIN-Trunk 中的“HigherLower”游戏。
• 我第一次没有正确了解历史记录，因此很难从应用程序的一个部分导航到另一个部分。我的做法是不了解历史，这是严重的衰退。

我对这些问题的解决方案：

• 使用 GIN 删除难以维护的设置样板
• 从 Gwt-Ext 迁移到 GXT 时，使用其 MVC 框架作为 EventBus 来附加/分离模块化屏幕，以避免缓存/同步问题
• 想像 Ray Ryan 在 I/O 09 演讲中描述的某种“地点”抽象，它弥合了 GXT-MVC 和 GWTs-Hitory 方法之间的事件差距
• 使用 MVP 来隔离数据访问

概括：

我认为人们不能对整个应用程序使用单一的“MVP”方法。人们肯定需要应用程序导航的历史记录、像 GXT-MVC 这样的事件总线来附加/分离屏幕，以及 MVP 来轻松测试小部件的数据访问。

因此，我提出了一种结合这三个要素的分层方法，因为我相信“单事件 MVP 系统”解决方案行不通。导航/屏幕附加/数据访问是三个独立的问题，我将在接下来的几个月中重构我的应用程序（迁移到 GXT），以便分别针对每个问题使用所有三个事件框架（这项工作的最佳工具）。所有三个元素不需要互相了解。我确实知道我的解决方案仅适用于 GXT 项目。

当编写大型GWT应用程序时，我觉得我必须在客户端重新发明像Spring-MVC这样的东西，这真的很糟糕，因为需要花费大量的时间和脑力才能吐出像Spring MVC这样优雅的东西。GWT 更需要一个应用程序框架，而不仅仅是编译器人员辛勤工作的那些微小的 JS 优化。

Answer 3

下面是最近对架构GWT应用程序谷歌的IO演示。

享受。

-jP

Answer 4

如果您有兴趣使用的MVP架构，你可能想看看GWTP：的 http://code.google.com/p/gwt-platform/ 。这是一个开源的MVP框架我的工作，支持GWT的许多不错的功能，包括代码分裂和历史管理，用一个简单的基于注解的API。这是相当近期的，但已经在若干项目使用。

Answer 5

你应该看看 GWT Portlet. 。我们在开发大型 HR 门户应用程序时开发了 GWT Portlet 框架，现在它是免费且开源的。来自 GWT Portlet 网站（托管在 Google 代码上）：

编程模型有点类似于为门户服务器（Liferay、JBoss Portal 等）编写 JSR168 portlet。“门户”是使用 GWT Portlets 框架作为库构建的应用程序。应用程序功能被开发为松散耦合的 Portlet，每个 Portlet 都有一个可选的服务器端 DataProvider。

每个 Portlet 都知道如何将其状态外部化为可序列化的 PortletFactory 子类（momento / DTO / 工厂模式），从而使重要功能成为可能：

• CRUD 操作由所有 Portlet 的单个 GWT RPC 处理
• Portlet 在“页面”上的布局可以表示为 WidgetFactory 的树（PortletFactory 实现的接口）
• WidgetFactory 的树可以在服务器上与 XML 进行序列化和编组，以将 GUI 布局（或“页面”）存储在 XML 页面文件中

该框架的其他重要功能如下：

• 可以使用框架布局编辑器在运行时（由开发人员和/或用户）在浏览器中编辑页面
• Portlet 是绝对定位的，因此可以使用滚动区域
• Portlet 是可配置的，指示它们何时忙于加载以进行自动“加载微调器”显示，并且可以最大化
• 主题小部件，包括样式对话框、CSS 样式按钮替换、小工具按钮和 HTML 模板驱动菜单

GWT Portlet 用 Ja​​va 代码实现，不包装任何外部 Javascript 库。它不强加任何服务器端框架（例如Spring 或 J2EE），但被设计为与此类框架配合良好。