GWT 中的 MVP：最佳设计实践

Question

我在 GWT 项目站点的 MVP 教程上阅读过，视图应该只包含它包含的小部件的事件处理程序，并且处理它们的逻辑应该驻留在演示器中。关于这一点，我有以下疑问：

1. 很多时候我们需要根据视图上接收到的事件来动态改变小部件的样式，那么在prsenter中移动这种逻辑是否有意义？

2. 很多时候，我们需要从视图中的多个字段获取数据并创建一个对象并将其传递给某个小部件，例如具有自己的 asyncDataProvider 的 cellTable。 那么为所有视图字段创建getter和setter是否有意义，以便演示者可以访问它们并形成对象并初始化cellTable并将对象传递给它？ 在演示者的视图面板中添加小部件是个好主意吗？

3. 我在所有地方都读到，将逻辑添加到演示者而不是视图的原因是为了增加 jUnit 测试覆盖率，从而节省时间。但是，据我所知，我们也可以在 View 上使用 mocking 框架来为其中的基本逻辑编写测试用例。

4. 考虑到第 3 点，在视图中编写这么多代码（getter/setter）真的有意义吗？我相信只有在以下情况下，流程才应该从视图返回到演示者：

   一个。我们需要切换视图

   b.我们没有要在视图中显示的数据，因此演示者可以通过 RPC 提供它

Answer 1

对于初学者，请参阅 Google IO 2013 的 Demystifying MVP and EventBus in GWT (slides) 演示文稿。 这是对整个 MVP + GWT 方法的更新，应该可以回答您的一些疑问和问题。

一般来说，当谈到 MVP 和设计应用程序的架构时，有很多意见和方法。所以，YMMV。

1. 我会问自己 - 这是对数据状态的更改吗？或者只是对演示文稿的更新？在后一种情况下，我会将其保留在视图中，否则视图的界面会变得不必要地臃肿。
2. 在这种情况下，您可能需要考虑创建一个Editor。然后，您可以使用编辑器的界面来编辑和刷新数据 - 您不必公开所有单独的字段。
3. 确实如此 - 请参阅上面的演示文稿，其中提到在某些情况下将视图和演示者分开是没有意义的。尤其是当我们拥有 gwtmockito 等工具时。
4. 这取决于您如何对待您的视图 - 它们是哑视图、不包含逻辑并且由演示者控制吗？一方面，这可以很好地分离，另一方面，正如您所提到的，视图的界面往往会变得非常冗长。我试图寻找这两种方法之间的最佳平衡点，但这实际上取决于您的编码风格和用例。