java – 摆脱GWT MVP样板

前端之家收集整理的这篇文章主要介绍了java – 摆脱GWT MVP样板前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
关于地点和附件的文件活动MVP,我必须创建的每个页面

>一个地方
>一项活动
>一个标记化器(我必须实现标记化逻辑)
>演示者的界面(活动实现此界面)
>视图的界面
>视图实现
>用于视图实现的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逻辑.它完成了我目前的项目,让我很开心.

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

原文链接:https://www.f2er.com/java/128854.html

猜你在找的Java相关文章