GWT 小部件与 MVP答案

【问题标题】：GWT widgets vs MVPGWT 小部件与 MVP
【发布时间】：2012-03-15 23:23:54
【问题描述】：

我正在寻找有关 GWT 架构的指导 - 何时使用自包含小部件与 MVP/Activity/Places。

背景

阅读了 Google 文档并搜索了 Stackoverflow，gwt-examples 项目为这个问题提供了最好的说明：http://code.google.com/p/gwt-examples/source/browse/trunk_2012/DemoGwtEditor/src/com/gonevertical/client/?r=3138#client%2Fviews

一个应用程序被划分为强解耦视图，每个视图对应一个 DOM 对等体。活动和地点用于管理给定视图的逻辑/RPC 和导航。虽然不精确，但为了简洁起见，我将这种模式称为 MVP。

小部件不符合此模式，包含视图和逻辑/RPC 调用。

上下文

对于这个问题的上下文，我正在考虑一个复杂的 GWT 应用程序，它使用 TabLayoutPanel 创建单独的“屏幕”。每个选项卡/屏幕都广泛地与用户活动相关。 Mint.com 就是这种界面的一个很好的例子：仪表板选项卡、交易选项卡、预算选项卡、趋势选项卡等。每个选项卡都由许多子组件构建而成：图表带有选择器、报告选择器、事务表等。

像事务表这样的子组件可能是多个 GWT 原生组件的组合 - 例如。一张有几个按钮的桌子。 Google doco 将这种子组件显示为被分解为 MVP。

假设 - 小部件与 MVP

用 MVP 处理子组件意味着：

每个选项卡的非常大的视图和活动/演示者类或
嵌套 MVP 和文件爆炸（每个子组件 5 个）

另一方面，作为小部件的子组件意味着：

非常轻量级的 MVP 结构，仅用于管理导航历史标签;不值得
没有解耦（单元测试和切换很困难视图）

问题

这些假设是否正确？
何时在解耦视图/MVP 上使用自定义复合小部件（反之亦然）？

【问题讨论】：

标签： gwt

【解决方案1】：

要回答这个问题，您首先必须查看活动和地点 - 因为活动通常兼具演示者的双重职责。活动管理器负责屏幕的某个区域。例如，选项卡区域可以由活动管理器控制，其中每个活动都是不同的选项卡。这表明每个选项卡都有自己的演示者。演示者只需要了解它需要将数据加载到/加载出的视图 UI 部分（如果只编辑数据，您可以将其减少到仅编辑器驱动程序）以及它需要响应事件的项目。演示者不需要知道仅与视图响应有关的视图事件，例如披露面板或被选中的事物。演示者唯一参与的情况是 UI 发送需要一些业务/模型逻辑的事件 - 例如在列表项上显示更多详细信息、创建新列表项或保存模型。

这有帮助吗？

【讨论】：

谢谢迪安娜。这听起来像是对 MVP 选项 1（每个选项卡的非常大的视图和活动/演示者类）的支持，因为演示者有明确的职责 - 对吗？在此模型中，您将如何管理大量可能可重复使用的 UI 部件？
我会将可重复使用的部分制作成独立的小部件。如果他们需要业务/模型逻辑作为其中的一部分，那就很棘手了。小部件不需要关心模型，而只关心 UI 的工作方式。因此，在这种情况下，我将创建演示者可以用来绑定到可重用小部件的接口和事件。抽象地谈论它有点困难。如果你能给我举个例子会更容易。
示例：“事务”选项卡有两个组件：1，一个带有关联的添加/删除/保存按钮的可编辑表格；2，一个使用从表格中选择的行绘制的可重复使用的图表。
对于表格，除非逻辑有特殊之处或需要特殊的html，否则不需要可重用。但是您可能会考虑将演示者设置为它自己的类并重用它的部分。该图表将取决于您使用了多少特殊代码。您是从画布元素创建它，还是使用图表库？如果它来自库，那么我可能会像演示者一样做它，并分解出一个迷你演示者类以在更大的演示者中使用。如果您是从画布上滚动自己的图表，则将其设为小部件。
这是非常好的经验法则。同时意识到单片演示者是由控制屏幕一个区域的活动管理器管理的。一如既往地牢记目标，presenters 是 junit 可测试的单元，视图可以替换为 mock 进行测试。

【解决方案2】：

自定义小部件和 MVP 没有可比性。它们不是一个问题的答案选项，而是两个不同问题的答案。

问题 1：我应该什么时候编写自定义小部件？问题 2：我应该使用 MVP（还是应该使用 MVC 还是不应该使用任何模式）？

先回答问题2：

使用 MVP

对于具有多个屏幕/活动的应用程序，如果代码结构过于简单（用户界面、服务器命令、用户界面事件处理等）在同一个地方，您会觉得管理起来会很麻烦
当您知道您将拥有多个 UI 来实现相同的功能时。例如，将在桌面浏览器和移动浏览器上使用的应用程序。您可以在桌面和移动设备上使用完全不同的“视图”实现
当您希望进行单元测试或测试驱动开发时
如果（您或您的团队）有使用 MVC 或 MVP 等框架的经验

使用自定义小部件

当您没有可用于此目的的小部件时
当您使用多个小部件来实现某些功能时。例如，如果您想要一个文本字段，则用户在该字段中键入，然后您在客户端处理输入，并将其显示在标签中。现在假设您希望在不止一个地方使用此功能。编写可重用的代码是明智的。自定义小部件可以做到这一点
当您想要增强现有小部件的功能时。例如，您希望按钮的默认单击处理程序以某种方式处理

【讨论】：

【解决方案3】：

小部件和 MVP 之间的区别并不像您想象的那么明显。
您可以使用 MVP 模式很好地实现小部件。

GWT 自己的 CellWidgets 就是一个例子。
像 CellTable 这样的 CellWidgets 在内部使用 presenters 和视图来将视图与逻辑/状态分离。这使得对它们进行单元测试变得容易。

我认为没有完美的解决方案，它可能还取决于用例/应用程序。我通常会尽量避免从小部件本身进行后端调用（RPC 左右）。我尝试以某种方式设计小部件，即它们处理并最终显示的数据由演示者从外部设置。
因此，基本上，小部件只是视图之类的子组件，由演示者填充和控制，并嵌入在视图中。

如果您想拥有更复杂的小部件，其中还包含业务逻辑和后端调用，请尝试将 MVP 模式应用于小部件。

这还取决于您使用的是哪种 MVP 框架。对于活动和地点（好吧，严格来说不是 MVP 框架），您通常没有嵌套的演示者（请参阅 Thomas Broyer blog）。
当您使用具有PresenterWidgets 概念并允许嵌套演示者的GWTP MVP 框架时，情况就不同了。

【讨论】：