25

クライアント向けに新しいGWTプロジェクトを開始したばかりで、さまざまなGWTMVCアーキテクチャに関する人々の経験を聞くことに興味があります。最近のプロジェクトでは、GXT MVCとカスタムメッセージングソリューション（AppceleratorのMQに基づく）の両方を使用しました。GXT MVCは問題なく動作しましたが、GWTにとってはやり過ぎのようで、ブラウザーの履歴を処理するのは困難でした。PureMVCとGWTigerについて聞いたことがありますが、使用したことはありません。カスタムMQソリューションは非常にうまく機能しましたが、JUnitを使用してコンポーネントをテストすることは困難でした。

さらに、Google Wave（GWTアプリケーション）はModel-View-Presenterパターンを使用して記述されていると聞きました。サンプルのMVPアプリケーションが最近公開されましたが、コードを見ると、それほど直感的ではないようです。

新しいGWTアプリケーションを構築する場合、どのアーキテクチャを使用しますか？あなたが選んだ長所と短所は何ですか？

ありがとう、

マット

4

5 に答える 5

17

グーグルがついにmvpアーキテクチャを使用して設計するためのチュートリアルを書いたことは注目に値します。それは上記のグーグルi/oトークからの多くの要素を明らかにします。見てみましょう： https：//developers.google.com/web-toolkit/articles/mvp-architecture

于 2010-01-03T22:48:27.813 に答える
11

GWT desperatleyには、アプリケーションを構造化するためのRailsのような方法が必要なので、この質問が寄せられてうれしいです。すべてのユースケースの90％で機能し、非常に簡単なテスト容易性を可能にする、ベストプラクティスに基づくシンプルなアプローチ。

過去数年間、私はMVPの独自の実装を使用しており、プレゼンターが指示したことすべてに自分自身を奴隷化する非常に受動的な見方をしています。

私の解決策は次のもので構成されていました。

  • 外観を制御するためのメソッドを定義するウィジェットごとのインターフェース
  • Compositeにすることも、外部ウィジェットライブラリを使用することもできる実装クラス
  • M個のウィジェットで構成されるN個のビューをホストする画面の中央プレゼンター
  • 現在の視覚的外観に関連するデータを保持する画面ごとの中央モデル
  • "SourcesAddEvents [CustomerDTO]"のようなジェネリックリスナークラス（エディターはここでJavaジェネリックの実際のシンボルを好まないので、ブラケットを使用しました）。

ビューは、コンストラクターパラメーターとしてプレゼンターへの参照を取得するため、プレゼンターを使用してイベントを初期化できます。プレゼンターはこれらのイベントを処理し、他のウィジェット/ビューに通知するか、gwt-rpcを呼び出して、成功するとその結果をモデルに入れます。モデルには、プレゼンターに登録されている典型的な「Property [List [String]] names = ....」プロパティ変更リスナーメカニズムがあり、gwt-rpcリクエストによるモデルの更新がすべてのビュー/ウィジェットに送信されます。興味がある。

このアプローチにより、AsynInterfaces用のEasyMockを使用して非常に簡単にテストできるようになりました。また、ビュー/ウィジェットの実装を簡単に交換できるようになりました。これは、基になるウィジェット（ボタン、リンクなど）に関係なく、あるイベントをプレゼンターに通知するコードだけを書き直す必要があったためです。

私のアプローチの問題：

  • 私の現在の実装では、異なる画面の中央モデル間でデータ値を同期することが困難になっています。カテゴリのセットを表示する画面と、それらのアイテムを追加/編集できる別の画面があるとします。現在、これらの変更イベントを画面の境界を越えて伝播することは非常に困難です。これは、値がこれらのモデルにキャッシュされ、一部がダーティであるかどうかを確認するのが難しいためです（従来のweb1.0-htmlでは簡単でした）。 -サーバーサイドの宣言型キャッシングを使用したダム端末のようなシナリオ）。
  • ビューのコンストラクターパラメーターを使用すると、非常に簡単なテストが可能になりますが、確実なDependency-Injectionフレームワークがないと、「onModuleLoad（）」内にいくつかの醜いファクトリ/セットアップコードが含まれます。これを始めたとき、私はGoogle GINを知らなかったので、アプリをリファクタリングするときに、この定型文を取り除くためにそれを使用します。ここでの興味深い例は、GIN-Trunk内の「HigherLower」ゲームです。
  • 初めて履歴を正しく取得できなかったため、アプリのある部分から別の部分に移動するのは困難です。私のアプローチは、深刻な不況である歴史を認識していません。

それらの問題に対する私の解決策：

  • GINを使用して、保守が難しいセットアップボイラープレートを取り外します
  • Gwt-ExtからGXTに移行するときは、MVCフレームワークをEventBusとして使用して、モジュラースクリーンをアタッチ/デタッチし、キャッシュ/同期の問題を回避します。
  • ある種の「場所」について考えてみてください-レイ・ライアンのような抽象化は、I / O 09での彼の講演で説明されており、GXT-MVCとGWTの間のイベントギャップを埋めます-歴史的アプローチ
  • ウィジェットにMVPを使用して、データアクセスを分離します

概要：

アプリ全体に単一の「MVP」アプローチを使用できるとは思いません。アプリナビゲーションの履歴、画面をアタッチ/デタッチするGXT-MVCのようなイベントバス、ウィジェットのデータアクセスを簡単にテストできるMVPが明らかに必要です。

したがって、「one-event-mvp-system」ソリューションは機能しないと考えているため、これら3つの要素を組み合わせた階層型アプローチを提案します。ナビゲーション/画面添付/データアクセスは3つの個別の懸念事項であり、今後数か月以内にアプリをリファクタリング（GXTに移行）して、各懸念事項の3つのイベントフレームワークすべてを個別に利用します（仕事に最適なツール）。3つの要素すべてがお互いを認識する必要はありません。私のソリューションがGXTプロジェクトにのみ適用されることを私は知っています。

大きなGWTアプリを作成するとき、Spring MVCのようなエレガントなものを吐き出すには多くの時間と頭脳の力がかかるため、クライアントでSpring-MVCのようなものを再発明する必要があるように感じます。GWTには、コンパイラーの人たちが一生懸命取り組んでいる小さなJS最適化よりもはるかに多くのアプリフレームワークが必要です。

于 2009-08-06T08:15:20.037 に答える
3

MVP アーキテクチャの使用に興味がある場合は、GWTP を参照してください: http://code.google.com/p/gwt-platform/。これは私が取り組んでいるオープン ソースの MVP フレームワークであり、単純な注釈ベースの API を使用して、コード分割や履歴管理など、GWT の多くの優れた機能をサポートしています。これはごく最近のものですが、すでに多くのプロジェクトで使用されています。

于 2010-04-13T19:14:50.217 に答える
1

GWTPortletsを確認する必要があります。大規模なHRポータルアプリケーションに取り組んでいる間にGWTポートレットフレームワークを開発しました。これは現在、無料でオープンソースです。GWT Portlets Webサイト（Googleコードでホストされている）から：

プログラミングモデルは、ポータルサーバー（Liferay、JBoss Portalなど）用のJSR168ポートレットの作成にいくぶん似ています。「ポータル」は、GWTポートレットフレームワークをライブラリとして使用して構築されたアプリケーションです。アプリケーション機能は、それぞれがオプションのサーバー側DataProviderを備えた疎結合ポートレットとして開発されています。

すべてのポートレットは、その状態をシリアル化可能なPortletFactoryサブクラス（momento / DTO /ファクトリパターン）に外部化して、重要な機能を可能にする方法を知っています。

  • CRUD操作は、すべてのポートレットに対して単一のGWTRPCによって処理されます
  • 「ページ」上のポートレットのレイアウトは、WidgetFactoryのツリー（PortletFactoryによって実装されるインターフェース）として表すことができます。
  • WidgetFactoryのツリーは、サーバー上のXMLとの間でシリアル化およびマーシャリングして、GUIレイアウト（または「ページ」）をXMLページファイルに保存できます。

フレームワークの他の重要な機能を以下に示します。

  • フレームワークレイアウトエディターを使用して、実行時に（開発者やユーザーが）ブラウザーでページを編集できます。
  • ポートレットは絶対に配置されているため、スクロール領域を使用できます
  • ポートレットは構成可能であり、自動「ローディングスピナー」表示のためにローディングがビジーであることを示し、最大化することができます
  • スタイル付きダイアログボックス、CSSスタイル付きボタンの置換、小さなツールボタン、HTMLテンプレート駆動型メニューなどのテーマウィジェット

GWTポートレットはJavaコードで実装されており、外部のJavascriptライブラリをラップしません。サーバー側のフレームワーク（SpringやJ2EEなど）を強制することはありませんが、そのようなフレームワークと組み合わせてうまく機能するように設計されています。

于 2009-08-19T20:01:51.173 に答える