5

この記事を読んだだけで、かなり混乱しました。

第二に、このモデルにより、ブラウザーの存在に依存する GWTTestCase の使用を最小限に抑えることができ、コードの大部分について、軽量 (かつ高速) JRE テスト (ブラウザーを必要としない) を作成できます。[1]

これは、この設計パターンに従うことで得られるすべての利点ですか? コードが複雑になりそうです... このパターンを使用しますか?

4

3 に答える 3

8

特にGWTの場合、MVPはコードの複雑さを軽減します。中規模から大規模の GWT プロジェクトを計画している場合は、MVP アーキテクチャが主な選択肢です。GWT MVP (Google による) と gwt-platform (KennethJ による提案) の両方を見ることをお勧めします。他の実装もあります。

MVP の主な利点 (GWT MVP だけでなく、MVP パターンを意味します):

  • GWT UI とビジネス ロジックの明確な分離。すべてのクライアント側の Java コードは、GWT 実装への依存を最小限に抑えて (主にインターフェースを介して) 非常に汎用的になります。これはテストに非常に役立ちますが、それ自体が UI 設計の計り知れない利点です。
  • ビジネスロジックへの依存がほとんどないためUIの保守性が向上
  • GWT の依存関係が制限されているため、クライアントとサーバー間で共有されるコードの量が増加します

採用する可能性が高いその他の補完テクノロジ:

  • gwt-gin (Google Guice のクライアント側実装): gwtp はほぼ必須 (または必須 - 私はそれなしで試したことはありません)
  • クライアント コードとの一貫性のための Guice (サーバー側) ですが、技術的には必要ありません。
  • テスト モッキング フレームワーク (mockito など) は常に MVP で便利です
  • GWT UIBinder - UI 設計が非常に動的でない限り
  • GWT EventBus - AJAX/JavaScript のような非同期環境でのクライアント側通信の主な方法
  • コマンドパターン経由の GWT-RPC (gwtp ディスパッチャおよび/または RequestFactory)
于 2011-03-07T16:40:57.407 に答える
0

何と比較して利点？標準のMVCパターン（UI開発の一般的なパターン）と比較した場合の利点を意味する場合は、そうです、それがこのパターンの主な理由だと思います

GWTTestCaseは、標準のju​​nitテストよりもはるかに遅くて面倒です。標準のJavaテストフレームワークを使用してロジックをテストし、GWTTestCaseを使用してUI固有のロジックのみをテストする必要があります。

于 2011-03-06T17:02:31.693 に答える
0

GWTTestCase を使用しないという事実は、特にテスト駆動型開発を行う場合には非常に優れていますが、言及されている topchef のような他の大きな利点もあります。それは、使用する MVP の「バージョン」によって異なります。ビューから公開されたウィジェットのリスナーとして Presenter を登録している人々を見ると、うんざりします。

一般的に MVP を取り巻く問題の 1 つは、いくつかのフレーバーがあり、各フレーバーには異なる長所と短所があるため、パターンに慣れていない人が混乱することです。次の 2 つの記事を参照して、MVP が自分に適しているかどうかを判断し、MVP の詳細を確認してください (MVP と混同される可能性があるその他の事項と併せて): GWT MVP パターンおよびGWT MVP, アクティビティと場所の混乱。

于 2012-09-07T11:30:10.167 に答える