7

私は GWT アプリケーションで 1 年間働いていますが、これらのフレームワークやツールを使用する必要性を感じたことはありません。

だから、私たちはおそらく逃しているような気がします。

「コードビハインド」スタイルで行います。

コードの作成方法の簡単な例を次に示します。

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());
     }
  });
}

パネル (ページの一部、それぞれが独自のクラス) 間で通信するには、ウィジェットまたはアプリケーションのイベントバスを使用してカスタム イベントを送信します。

ナビゲートするには、場所/トークナイザー/アクティビティとヒストリーマッパーを使用します

単体テストと機能テストには、gwt-test-utilsを使用します。

以上です。だから私は疑問に思っています: これらのツールはどのような痛みに役立ちますか? それらを使用する説得力のある理由は何ですか?

ありがとう

4

4 に答える 4

2

MVP はビュー コードからロジックを分離するだけで、遅い GWTTestcase を使用する代わりに jvm でテストを実行するのに役立ちます。

エディターは、オブジェクト プロパティを入力フィールドにバインドするのに役立ちます。これにより、入力フィールドからコピーしてオブジェクトにコピーするコードが不要になります。

ジンは、オブジェクトの配線に役立ちます。繰り返しますが、これによりテストがはるかに簡単になります。オブジェクトを自分で配線することはできますが、ジンが自動的にそれを行うのであれば、なぜそれを行う必要があるのでしょうか?

RequestFactory は RPC アプローチの代替であり、よりデータ中心です。バッチ操作でデータをフェッチするのに役立ち、DTO を使用しなくなります。もちろん、RPC アプローチに固執することもできます。しかし、いくつかの欠点があります。Service ごとに Serverlet を作成するか、コマンド パターンを使用する必要があります。これは、非常にリクエストに対してアクション、レスポンス、および処理サービスを作成する必要があるという問題につながります。これは、維持する必要のある大量のコードです。

于 2012-09-26T12:37:42.073 に答える
1

私が検討することを提案するかもしれない1つのことは、RequestFactoryとgwtrpcです。オブジェクトをシリアライズ可能にする必要はなく、差分のみをネットワーク経由で送信するなど、パフォーマンスが大幅に向上しています。

また、ginに似たClientFactoryパターンを使用します。これを使用して、使用されているデバイスタイプ（タブレット、モバイル、デスクトップ）に応じてクライアントクラスを挿入します。

于 2012-09-26T12:37:07.723 に答える
0

あなたのアプローチは大丈夫です。実際、私はこのようなプロトタイプ プロジェクトの多くを開始しました (このようなプロジェクトでは、gwt-test-utils の代わりに GWTTestCase を使用します)。そして、ご存知のように、これだけで十分な場合もあり、それ以外はすべて複雑になるだけです! したがって、プロトタイプだけでなく、実際のプロジェクトでもうまく機能する可能性があります。

しかし、多くの場合、いくつかのコンポーネントを再利用して、それらをより構成可能にしたいことがわかりました。そして、これが私が MVP にリファクタリングする時です。そして、まだ行っていない場合は Gin (実際、最近では通常、すべてのプロジェクトを Gin で開始します)。

したがって、それらの必要性または特定の利点を発見したときに、これらのことを追加できます（理論的に優れている、または「ヒップ」であるからではありません）。

ところで、私はイベント バス アプローチを使用しません (小さくて明確に定義されたイベントのセットを除く)。これは、イベント システムの複雑さが爆発的に増大することが多いためです。

于 2012-09-26T12:54:10.897 に答える