GWT小部件与MVP

我正在寻找关于GWT架构的指导——何时使用自包含的小部件与MVP/活动/场所

背景 在阅读了Google docs&Scored Stackoverflow之后，gwt示例项目为这个问题提供了最好的说明：

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

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

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

像事务表这样的子组件可能是几个GWT本地版本的组合，例如，一个带有几个按钮的表。GoogleDoco将这种子组件分解为MVP

假设-小部件与MVP 用MVP处理子组件意味着：

• 每个选项卡或
• 嵌套MVP&文件爆炸（每个子组件5个）

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

• 非常轻的MVP结构，仅用于管理跨平台的导航历史记录 标签；不值得
• 无解耦合（因此单元测试和切换很困难 （视图）

问题

• 这些假设正确吗
• 什么时候在去耦合视图/MVP上使用定制的复合小部件（反之亦然）

---

要回答这个问题，你首先要看活动和地点，因为活动往往是主持人的双重职责。活动管理器负责屏幕的特定区域。例如，选项卡区域可以由活动管理器控制，其中每个活动都是不同的选项卡。这表明每个选项卡都有自己的演示者。演示者只需要知道需要将数据加载到/输出到的视图UI部分（如果只编辑数据，则可以将其简化为编辑器驱动程序）以及需要在事件中响应的项目。
演示者不需要知道仅与视图响应有关的视图事件，例如公开面板或被选中的内容。演示者唯一参与的时间是UI发送需要一些业务/模型逻辑的事件时，例如显示列表项的更多详细信息、创建新列表项或保存模型

---

这有帮助吗？

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

GWT自己就是一个例子。
像

CellTable

这样的CellWidget在内部使用and视图将视图与逻辑/状态解耦。这使得单元测试变得很容易

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

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

这还取决于您使用的是哪种MVP框架。对于活动和场所（好的，严格来说不是MVP框架），您通常没有嵌套的演示者（请参见Thomas Broyer）。

---

这与使用MVP框架不同，MVP框架具有嵌套演示者的概念并允许嵌套演示者

自定义小部件和MVP是不可比较的。它们不是一个问题的答案选项，而是两个独立问题的答案

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

首先回答问题2：

使用MVP

• 对于具有多个屏幕/活动的应用程序，如果代码结构过于基本，您会觉得难以管理这些屏幕/活动—ui、服务器命令、ui事件处理等位于同一位置
• 当您知道同一功能将有多个UI时。例如，将在桌面浏览器和移动浏览器上使用的应用程序。对于台式机和移动设备，您可以有完全不同的“视图”实现
• 当您希望进行单元测试或测试驱动开发时
• 如果（您或您的团队）有使用MVC或MVP等框架的经验

使用自定义小部件

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

---

谢谢迪安娜。这听起来像是对MVP选项1（每个选项卡都有非常大的视图和活动/演示者类）的支持，因为演示者有明确的责任，对吗？如何管理大量潜在的可重用UI部件