これは完全に維持不可能だと思います
私はあなたに同意しません。小さなファイルが多数ある方が、大きなファイルをいくつか結合するよりもメンテナンスに適しています。GWT はSpring MVC よりもはるかに冗長であることに同意します。
- JSP の動的な性質のため、これらすべてのインターフェースは必要ありません。
- Spring MVC の場合の JSP は厳密に型付けされておらず、多くの低レベルの処理を自動的に実行できます (データ バインディングなど)。
- また、いくつかのことをまったく行わないでください (リクエスト間でビューをクリーンアップする必要はありません。ビューはステートレスです)。
Java とステートフル ビューの厳密な性質による GWT の場合、多くの追加作業を行う必要があります。完全に保守可能です (正しく行われた場合)。主な利点は、プレゼンテーション層の単体テストを追加できることです。この事実により、複雑な UI、大規模なコードベース、大規模なチームを持つ長期実行プロジェクトの保守が容易になります。あなたのプロジェクトに当てはまらない場合 (画面が単純で、UI レイヤーの単体テストを追加する予定がない場合)、次のことをお勧めします。
- 別のより軽量なプレゼンテーション技術 (Spring MVC など) を使用します。
- または、ポリシーを簡素化します (たとえば、プレゼンターを許可する -> インターフェイスなしでインタラクションを表示する)。通常、この場合、プレゼンターを単体テストできなくなります。@Andrea Boscolo が述べたように、この問題の回避策としてGwtMockitoを使用できます。
ビューとプレゼンター間のインターフェイスのもう 2 つの利点:
- ビューの実装を簡単に切り替えることができます (デスクトップ UI の作成に関する有名なケース -> モバイル UI の切り替えは、残念ながら実装されたことはありません)。
- 私にとって、それはプレゼンテーション ロジックをプレゼンターに保持するのに役立つある種の障壁です。プレゼンターは必要なことしか知らない。私はこのコンセプトが好きです。これにより、すべての部分を適切な場所に書くことができます。
これらすべてのファイルで本当に悩ましいのは、1 つのアクティビティをセットアップするのに非常に時間がかかることです。簡単にするには:
- Eclipse で UiBinder テンプレートを使用していることを確認してください
- さらに、アクティビティ名とパッケージをパラメーターとして受け取り、必要なものをすべて生成するコード ジェネレーターを作成できます。したがって、ActivityMapper を変更して、重要な UI ロジックの作成を開始するだけです。それは私の現在のプロジェクトのために行われ、私を幸せにします.
ボイラープレートのもう 1 つのソースは、データ バインディングです。エディター フレームワークの使用を検討してください。