摆脱GWT MVP样板代码

Question

根据地点和活动+MVP文档，我需要为每个页面创建以下内容：

• 一个地点
• 一个活动
• 一个分词器（我必须实现分词逻辑）
• 一个呈现者接口（活动实现此接口）
• 一个视图接口
• 视图实现
• 用于视图实现的UI Binder XML
• 应用程序活动映射器中的节点
• Gin模块中将视图接口绑定到视图实现的节点

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

使用Spring MVC或Play，我可以在大约200行中实现相同的功能。

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

- David Frank

Answer 1

我认为这是完全无法维护的。

我不同意你的看法。相比于几个大文件，大量小文件更易于维护。我同意 GWT 比 Spring MVC 更加冗长：

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

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

• 使用更轻量级的演示技术（例如Spring MVC）。
• 或简化您的策略（例如允许presenter -> view交互而不需要接口）。在这种情况下，通常会失去单元测试presenters的能力。正如@Andrea Boscolo所提到的，您可以使用GwtMockito来解决此问题！

视图和presenters之间接口的另外两个优点：

• 您可以轻松切换视图实现（著名的案例是制作桌面UI ->移动UI切换，但我从未看到过实现）
• 对我来说，这是一种帮助保持演示逻辑在presenter中的屏障。Presenter只知道必要的事情。我喜欢这个概念。这有助于我将所有部分写在正确的地方。

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

• 确保您在eclipse中使用UiBinder模板
• 甚至更多，您可以编写代码生成器，该生成器将活动名称和包作为参数，然后它将生成所有必要的内容。因此，您只需要修改ActivityMapper并开始编写重要的UI逻辑。这已经为我的当前项目完成，让我感到很高兴。

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

- Maksym Demidas

---

谢谢你的回答，我已经移除了接口。实际上，我正在独自开发整个应用程序，并且我认为在这个项目中为视图和Presenter创建接口并没有任何优势。 - David Frank

我会再开放这个问题几天，如果没有更好的答案出现，我会接受你的答案。 - David Frank

你的代码生成器想法听起来非常有用。我相信许多人可以从中受益。你能分享一下吗？ - bug

@bug 不是我的，所以我不能这样做。将来的项目中，我会尝试构建自己的版本并分享它。你也可以自己做（创建Maven插件，使用一些模板引擎生成文件）。据我所知，这并不是很难实现的。 - Maksym Demidas

Answer 2

使用MVP与GWT的主要好处是能够使用普通的JUnit TestCase 对Presenter进行隔离单元测试，而不是依赖于极其缓慢的GwtTestCase。其他好处，例如可维护性，可以通过使用简单的项目结构来实现，就像 @Maksym Demidas 指出的那样。

因此，真正的问题是你是否想要/需要在项目中进行这种程度的测试，以换取前面提到的样板文件成本。请注意，Places和Activities与MVP无关：你可以使用它们来实现MVP，但它们只是关于导航和视图之间的转换（URL）。

我真的建议您查看最近Erik Kuefler的Google IO 2013演示文稿 - Demystifying MVP and EventBus in GWT。它应该帮助您确定何时使用MVP，何时不使用。此外，请查看他发布的开源库，特别是GwtMockito（即，在普通的JUnitTestCase中测试小部件逻辑）。

- Andrea Boscolo