7

按照关于场所和活动 + MVP 的文档，对于我必须创建的每个页面：

  • 一个地方
  • 一个活动
  • 一个分词器（我必须实现分词逻辑）
  • 演示者的接口（活动实现此接口）
  • 视图的接口
  • 视图实现
  • 用于视图实现的 ui binder xml
  • 应用活动映射器中的一个节点
  • gin 模块中的一个节点，用于将视图接口绑定到视图实现

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

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

我做错了什么，您将如何解决？

4

2 回答 2

6

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

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

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

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

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

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

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

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

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

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

于 2013-08-08T13:58:11.423 回答
4

将 MVP 与 GWT 结合使用的主要好处是，能够使用普通的 JUnit 单独对演示者进行单元测试TestCase，而不是依赖于痛苦缓慢的GwtTestCase.

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

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

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

于 2013-08-09T12:15:30.177 回答