Question

我已经在GWT应用程序上工作了一年，我们从未觉得需要使用任何这些框架或工具。

所以我觉得我们可能错过了。

我们这样做是“代码背后”的风格。

以下是我们如何构建代码的简单示例：

MyPanel.ui.xml：

<label ui:field="label"/>
<g:TextBox ui:field="box"/>
<g:Button ui:field="button"/>

MyPanel.java：

@UiField
LabelElement label;
@UiField
TextBox box;
@UiField
Button button;

MyBean myBean;

Messages messages = GWT.create(Messages.class);
MyServiceAsync myServiceAsync = GWT.create(MyService.class);

...


protected void i18n() {
  label.setInnerText(messages.label());
  button.setText(messages.button());
}

...

@UiHandler("box")
void box_onValueChange(ValueChangeEvent<String> event) {
  myBean.setText(event.getValue());
}

@UiHandler("button")
void button_onClick(ClickEvent event) {
  myServiceAsync.sendData(myBean, new AsyncCallback<MyResponse>() {
     @Override
     public void onSuccess(ReponseDispoBean result) {
       Window.alert(result.message());
     }

     @Override
     public void onFailure(Throwable caught) {
       Window.alert(caught.getMessage());
     }
  });
}

要在面板之间进行通信（页面的各个部分，每个部分都在自己的类中），我们使用小部件或应用程序的eventbus来发送自定义事件。

要导航，我们使用places / tokenizers / activities和historymapper

对于单元和功能测试，我们使用gwt-test-utils

就是这样。所以我想知道：这些工具有什么用处？有什么令人信服的理由可以使用它们？

由于

Answer 1

编辑和 GIN 处理减少样板。
例如，比较相同的屏幕 without和with编辑器当我说GIN处理减少样板时，只有你已经使用依赖注入（DI）。如果您不使用DI，那么you probably should。

与DI类似， MVP 有助于制作可测试的代码，特别是关于测试表示逻辑（不一定是业务逻辑，而不是用户界面）。例如，如何显示某些内容并不重要，重要的是您在合适的时间显示正确的内容。一个例子就是错误：如果它们在屏幕顶部是红色，或者在表单字段旁边，或者在表单字段上的工具提示然后变为红色，则无关紧要;重要的是，您在适当的时间发送到视图正确的错误集。可以替换或修改如何（理想情况下也应该进行测试），但是相同的。
构建多因素应用程序时MVP也很棒：如果屏幕在移动设备，平板电脑和桌面设备之间足够相似，那么您可以使用具有3种不同视图的相同演示者（这就是DI闪耀的地方）！）。

对于 RequestFactory （RF），它是一个与GWT-RPC不同的客户端 - 服务器协议，具有自己的一组功能和限制。如果你没有GWT-RPC的问题，你不应该切换（虽然我建议你看看RF是什么）。对我来说，RF的主要特点是它是一个协议（基于JSON）而不是API：客户端和服务器上的类不必完全相同，只要它们足够兼容< / em>客户端和服务器相互理解（添加属性，将int更改为double等）;与GWT-RPC相比，这是一个巨大的差异，即使对于类中的非常微小和微妙的更改，您也会遇到错误。

但最后，“if it ain't broke, don't fix it”。

Answer 2

MVP只是将逻辑与视图代码分开，并有助于在jvm中运行测试，而不是使用慢速GWTTestcase。

编辑器有助于将对象属性绑定到输入字段。这使得从输入字段复制到输入字段的代码变得过时。

杜松子酒有助于连接物体。同样，这使测试变得更容易。您可以根据自己的原因连接对象，但如果杜松子酒为您自动执行此操作，为什么要这样做呢？

RequestFactory是RPC approch的替代品，更加以数据为中心。它可以帮助您在批处理操作中获取数据，并使DTO的使用过时。你可以坚持使用RPC方法。但是有一些缺点。您必须为每个服务创建一个Serverlet，或者您可以使用命令模式。这导致了问题，您必须为非常请求创建一个Action，Response和一个处理服务。这需要维护很多代码。

Answer 3

我建议看看的一件事是RequestFactory vs gwt rpc。它不需要对象可序列化，并且具有相当多的性能增强功能，例如只通过线路发送差异。

我们还使用类似杜松子酒的ClientFactory模式。我们使用它来注入客户端类，具体取决于正在使用的设备类型（平板电脑，移动设备，桌面设备）。

Answer 4

你的方法还可以。事实上，我已经启动了许多这样的原型项目（而不是gwt-test-utils，对于这样的项目，我只使用GWTTestCase）。而且你知道，有时候这就是所需要的，而其他一切只会增加复杂性！所以它不仅适用于原型，而且对于某些真实项目来说确实可以很好地工作。

但事实证明，我想重新使用一些组件，并使它们更具可配置性。这是我重构MVP的时候。和Gin如果我还没有（实际上，现在我通常用Gin开始所有项目）。

所以你可以添加这些东西，你发现它们的需要，或者某种优势（不是因为它们在理论上很棒，或者是“时髦”）。

顺便说一下，我没有使用事件总线方法（除了小的，定义明确的事件集），因为事件系统的复杂性通常会爆炸。

Gwt架构：为什么要使用MVP，编辑器，RequestFactory，Gin等？

4 个答案: