摆脱GWT MVP样板

Dav*_*ank 7 java mvp gwt gwt-mvp gwt-places

关于地点和活动+ MVP的文档,我必须为每个页面创建:

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

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

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

我做错了什么,你会如何解决?

Mak*_*das 6

我认为这完全不可维护

我不同意你的看法.与大型文件相比,大量小文件的维护要好得多.我同意GWT是多比Spring MVC的更详细:

  • 由于JSP的动态特性,您不需要所有这些接口
  • Sppring MVC案例中的JSP不是严格类型的,并且允许您自动执行许多低级别事务(例如数据绑定).
  • 并且根本不做某些事情(不需要清理请求之间的视图,视图是无状态的).

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

  • 使用另一种更轻量级的表示技术(例如Spring MVC).
  • 或简化您的策略(例如,允许演示者 - >查看没有接口的交互).通常,在这种情况下,您无法对演示者进行单元测试.正如@Andrea Boscolo所提到的,您可以使用GwtMockito作为此问题的解决方法!

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

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

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

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

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