GWT中的MVP：最佳设计实践

Question

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

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

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

3. 我读到的每个地方都有将逻辑添加到演示者而不是视图的原因是增加jUnit测试覆盖率，这样可以节省时间。但是，据我所知，我们可以在View上使用模拟框架来编写内部基本逻辑的测试用例。

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

   一个。我们需要切换视图

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

Answer 1

首先，请参阅Google IO 2013的Demystifying MVP and EventBus in GWT（slides）演示文稿。 这是对整个MVP + GWT方法的更新，它应该回答你的一些疑问和问题。

通常，在MVP和设计应用程序架构方面有很多意见和方法。所以，YMMV。

1. 我问自己 - 这是对数据状态的改变吗？或者只是更新演示文稿？在后一种情况下，我会将它保留在视图中，否则视图的界面会不必要地膨胀。
2. 在这种情况下，您可能需要考虑创建Editor。然后，您将使用编辑器的界面进行编辑和刷新数据 - 您不必公开所有单独的字段。
3. 这是真的 - 请参阅上面的演示文稿，其中提到在某些情况下，分隔视图和演示者没有意义。特别是当我们有gwtmockito等工具时。
4. 这取决于您对待观点的方式 - 他们是愚蠢的观点，不包含逻辑并由演示者控制？一方面，这就形成了一个很好的分离，另一方面，正如你所提到的，视图的界面往往变得非常冗长。我试图瞄准这两种方法之间的甜点，但这实际上取决于你的编码风格和用例。