GWT クライアント コードに MVC またはその他の UI パターンを使用してみましたか。さまざまなアプローチで直面した落とし穴/利点は何ですか?
6 に答える
Swing、Cocoa などの他の UI フレームワークと同じように GWT を扱う必要があると思います。MVC (または他のパラダイム) に関してこれらのフレームワークで意味のあることはすべて、GWT でも意味があります。MVC を使いすぎる人がいると思いますが、ほとんどのフレームワークよりも Cocoa での動作が気に入っています。ビューを作成すると、ビューのすべての動作を制御する ViewController が作成され、すべてのデータを含むモデル オブジェクトが作成されます。すべてのビジネス ロジックがどこにあるかについて独断的になる必要はないと思います。それが理にかなっている場所にある必要があるだけです。
落とし穴に関しては、GWT は純粋にフロント エンド テクノロジであるため、技術的にはバック エンドがサーバーのどこかに置かれているという主な問題に遭遇する可能性があります。これは、クラウドのどこかにデータを保存するクライアント サーバー Swing アプリケーションを作成することとそれほど違いがあるとは思いません。違いは、GWT は JavaScript にコンパイルされ、JavaScript Web アプリケーションのすべての制限があるため、フロント エンドでは単純に実行できないことがいくつかあることです。たとえば、PDF を作成してそれをユーザーに表示したい場合、GWT ではそれを行うことができず、バックエンドを呼び出してそれを行う必要があるとします。一方、Swing アプリでは、おそらく itext を使用してクライアント側で実行できます。
GWTのMVCパターンについては、この質問で説明しています。この質問には、この詳細なブログ投稿へのリンクもあります。
私が追加する唯一のことは、クライアント側のコード全体が「MVC」の「V」と見なすことができるということです。これにより、見方が変わる可能性があります。クライアント側のコードを独自のネストされたMVCコンポーネントと考えると、Javaであり、オブジェクト指向であるため、Swingアプリのように設計できます。GWT RPCのものを処理するために、ビューからできるだけ多くのコントローラーコードを引き出すことがあなたの利益になると思います。モデルは、クライアントではなくサーバーにモデルを配置するかどうかを決定する必要がある場合があるため、より問題になる場合があります。または、モデルプロキシなどを作成します。
http://code.google.com/p/gwt-mvc/が役に立ちます。
利点は次のとおりです。
- 読みやすいコントローラ
- 履歴トークンの管理
- コントローラーは JMock でテスト可能 (GwtTestCase は不可)
- 階層型 MVC
- ビュー、コントローラー、モデルのコーディングを開始するための単純な継承。
GWTruts(http://sourceforge.net/projects/gwtruts/)を試しましたか?また、GWTでビューとコントローラーを分離するオープンソースのGWTMVCフレームワークでもあります
JetBrains で開発され、いくつかの (現在はリリースされていない) 製品で使用されている最小限の MVC フレームワークである JetPad-Mappers を見ることができます。
免責事項、私はこのフレームワークの開発に携わっています。
ある種の MVC/MVP タイプ パターンを使用することは、GWT アプリが最小のプロジェクトを超える場合に非常に重要です。そうしないと、何が起こっているのかを制御できなくなります。
すでに言及したこととは別に、ここで見た GXT の MVC 実装もあります: http://www.bristol-gtug.org/?p=45
昨年の Google IO でのこの講演により、多くの人々が GWT での MVC/MVP について考え始めました: http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html。
私は最近、GWT ドキュメントに MVP アーキテクチャに関するチュートリアルもあることに気付きました。