GWT 小部件与 MVP

Question

我正在寻找有关 GWT 架构的指南 - 何时使用自包含小部件与 MVP/事件/场所。

背景

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

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

小部件不符合这种模式，包含 View 和逻辑/RPC 调用。

语境

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

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

假设 - 小部件与 MVP

使用 MVP 处理子组件意味着:

每个选项卡或

的非常大的 View 和事件/演示者类

嵌套 MVP 和大量文件(每个子组件 5 个)

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

非常轻的 MVP 结构只是为了管理导航历史
标签；几乎不值得

没有解耦(单元测试和切换很困难
意见)

问题

这些假设正确吗？

何时在解耦 View /MVP 上使用自定义的复合小部件(或反之亦然)？

Answer 1

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

这有帮助吗？