>一个地方
>一项活动
>一个标记化器(我必须实现标记化逻辑)
>演示者的界面(活动实现此界面)
>视图的界面
>视图实现
>用于视图实现的ui binder xml
> app活动映射器中的节点
> gin模块中的一个节点,用于绑定视图接口以查看实现
我创建了一个具有基本功能的应用程序(5页和导航栏),我已经有超过1500行代码和~40个文件.我认为这是完全不可维护的,但是我没有找到任何解决这个问题的方法.有几个框架(例如GWTP)实现了MVP,但它们也需要相同数量的样板.
我可以使用spring mvc或play在~200行中实现相同的功能.
我做错了什么,你会如何解决？
解决方法
I think this is completely unmaintainable
我不同意你的看法.与大型文件相比,大量小文件的维护要好得多.我同意GWT比Spring MVC更冗长：
>由于JSP的动态特性,您不需要所有这些接口
> Sppring MVC中的JSP没有严格的类型,并且能够自动执行许多低级别的操作(例如数据绑定).
>并且根本不做某些事情(不需要清理请求之间的视图,视图是无状态的).
在GWT的情况下,由于Java和状态视图的严格性,您必须做很多额外的工作.它完全可以维护(如果正确完成).主要优点是您可以为表示层添加单元测试.由于这个事实,对于具有复杂UI,大型代码库和大团队的长期运行项目来说,它将更加可维护.如果您的项目不是这样(屏幕很简单,并且您不打算为UI层添加单元测试),那么最好：
>使用另一种更轻量级的表示技术(例如Spring MVC).
>或简化您的政策(例如,允许演示者 – >查看没有界面的交互).通常,在这种情况下,您无法对演示者进行单元测试.正如@Andrea Boscolo所提到的,您可以使用GwtMockito作为解决此问题的方法！
视图和演示者之间接口的另外两个优点：
>您可以轻松切换视图实现(关于制作desctop UI的着名案例 – >移动UI切换,遗憾的是我从未见过实现)
>对我来说,这是一种障碍,有助于将演示逻辑保留在演示者中.演示者只知道必要的事情.我喜欢这个概念.这有助于我在正确的地方写下所有作品.
所有这些文件的真正含义是设置一个活动需要很长时间.为了简化它：
>确保在eclipse中使用UiBinder模板
>更重要的是,您可以编写代码生成器,将活动名称和包作为参数,然后它将生成所有必要的东西.因此,您只需修改ActivityMapper并开始编写重要的UI逻辑.它完成了我目前的项目,让我很开心.
另一个样板来源是数据绑定.考虑使用编辑器框架.
