摆脱GWT MVP样板

Question

关于地点和附件的文档活动+ MVP，我必须创建的每个页面：

• 一个地方
• 活动
• 一个标记化器（我必须实现标记化逻辑）
• 演示者的界面（活动实现此界面）
• 视图的界面
• 视图实现
• 用于视图实现的ui binder xml
• app activity mapper中的节点
• gin模块中用于绑定视图接口以查看实现的节点

我创建了一个具有基本功能的应用程序（5页和导航栏），我已经有超过1500行代码和~40个文件。我认为这是完全不可维护的，但是我没有找到任何解决这个问题的方法。有几个框架（例如GWTP）实现了MVP，但它们也需要相同数量的样板。

我可以使用spring mvc或play在~200行中实现相同的功能。

我做错了什么，你会如何解决？

Answer 1

  

我认为这完全是不可维护的

我不同意你的看法。与大型文件相比，大量小文件的维护要好得多。我同意GWT比Spring MVC 更多更冗长：

• 由于JSP的动态特性，您不需要所有这些接口
• Sppring MVC案例中的JSP没有严格类型，并且能够自动执行许多低级别的操作（例如数据绑定）。
• 根本不做一些事情（不需要清理请求之间的视图，视图是无状态的）。

在GWT的情况下，由于Java和状态视图的严格性，你必须做很多额外的工作。它是完全可维护的（如果正确完成）。主要优点是您可以为表示层添加单元测试。由于这个事实，对于具有复杂UI，大型代码库和大型团队的长期运行项目，它将更加可维持。如果您的项目不是这样（屏幕很简单，而您不打算为UI图层添加单元测试），那么最好是：

• 使用另一种更轻量级的表示技术（例如Spring MVC）。
• 或简化您的政策（例如，允许演示者 - ＆gt;查看没有界面的互动）。通常，在这种情况下，您无法对演示者进行单元测试。正如@Andrea Boscolo所提到的，您可以使用GwtMockito作为此问题的解决方法！

视图和演示者之间接口的另外两个优点：

• 您可以轻松切换视图实现（关于制作desctop UI的着名案例 - ＆gt;移动UI切换，遗憾的是我从未见过实现）
• 对我来说，这是一种障碍，有助于将演示逻辑保留在演示者中。演示者只知道必要的事情。我喜欢这个概念。这有助于我在正确的地方写下所有作品。

所有这些文件的真正含义是设置一个活动需要很长时间。为了简化它：

• 确保在eclipse中使用UiBinder模板
• 更重要的是，您可以编写代码生成器，将活动名称和包作为参数，然后它将生成所有必要的东西。因此，您只需修改ActivityMapper并开始编写重要的UI逻辑。它是为我当前的项目完成的，让我开心。

另一个样板来源是数据绑定。考虑使用编辑器框架。

Answer 2

将MVP与GWT结合使用的主要好处是能够使用普通的JUnit TestCase单独测试您的演示者，而不是依赖于非常缓慢的GwtTestCase。

其他好处，例如可维护性，可以使用像@Maksym Demidas指出的更简单的项目结构来实现。

所以真正的问题是，如果你想要/需要在你的项目中进行这种程度的测试，代价是前面提到的样板。请注意，地点和活动与MVP无关：您可以使用它们来实现MVP，但它们只是关于地点之间的导航和视图转换（URL s）。

我真的建议你看看最近的Erik Ku​​efler的Google IO 2013演示文稿 - Demystifying MVP and EventBus in GWT。它应该可以帮助您确定何时使用MVP以及何时不使用MVP。另外，看看他发布的开源库，特别是GwtMockito（即，在简单的JUnit TestCase中测试小部件的逻辑）。