GWT小部件与MVP

Question

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

背景

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

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

窗口小部件不符合此模式,包含视图和逻辑/ RPC调用.

上下文

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

像事务表这样的子组件可能是几个GWT本机的组合 - 例如具有几个按钮的表.谷歌doco将这种子组件显示为被解组为MVP.

假设 - 小部件与MVP

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

• 每个标签或的非常大的视图和活动/演示者类
• 嵌套MVP和文件爆炸(每个子组件5个)

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

• 非常轻松的MVP结构,只需管理选项卡的导航历史记录; 几乎不值得
• 没有解耦(因此难以进行单元测试和切换视图)

问题

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

Answer 1

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

这有帮助吗？