4

私はこれについてしばらく考えていましたが、プレゼンテーション層の JSF プロジェクトで Bean/クラスを編成する方法のベスト プラクティスをまだ考え出していません。もちろん、そこには多くの要因がありますが、私は議論したいと思います。これが私の現在の考えです：

表示ページ (データの表示) と編集ページ (データの追加、更新、削除) を含む基本的な JSF (残念ながらここではまだ JSF 1.xx のままです) アプリケーションを考えてみましょう。プロジェクトを整理する方法は次のとおりです。

スコープ指定された BackingBean をリクエストします。

  • 関連するものを表示します (保存ステータス、レンダリング ロジックなど)。1 回のリクエストでのみ必要なもの
  • アクション、アクション リスナー、値変更リスナー。複数のビューに適用できる場合は、独自のファイルに分割できます。

セッション スコープの BackingBean:

  • 1 つのリクエストよりも長く存在する必要があるもの。データベース データ、SelectItems など。
  • この Bean はリクエスト Bean に注入され、任意のデータ オブジェクトのインスタンスを格納します。

データ オブジェクト:

  • データ オブジェクトを Bean にするのは意味がないように思われるので、それらは別々に格納されます。これは、ユーザー、本、車など、ページに表示するオブジェクトです。オブジェクトには、getFormattedName() などのビュー ヘルパー メソッドを含めることができます。

ダオ:

  • ビジネス ロジック層とのすべての対話を処理する非 Bean オブジェクト。データ Bean をロードし、サブミットなどを準備します。私は通常、これを public static メソッドのクラスにします。

コンバーター、バリデーター:

  • 別ファイル

平均的な JSF アプリケーションで必要なのは、これだけのようです。私はこれを読みました: http://java.dzone.com/articles/making-distinctions-beforeと、ここでの返信: JSF バッキング Bean 構造 (ベスト プラクティス)ですが、全体像を把握できているとは感じませんでした。BalusC の回答は役に立ちましたが、アプリ全体をカバーしているようには見えませんでした。あなたの考えを聞かせてください！

4

1 に答える 1

1

あなたは一般的に正しい軌道に乗っていると思いますが、私はいくつかのことを異なる方法で行います:

  1. 私はあなたのDAOレイヤーを2つの別々のレイヤーに分割します.1つの純粋なDAOレイヤーは、さまざまなソース（データベース呼び出し、Webサービス呼び出し、ファイル読み取りなど）からデータを取得するだけです。次に、DAO 呼び出しへのパススルーと、追加の計算、アルゴリズム、または 1 つの JSF ビューに固有ではないその他の一般的なビジネス ロジックを含むビジネス ロジック レイヤーを作成します。

  2. MVC パターンでは、ManagedBean はコントローラーの役割を果たし、プレゼンテーション ロジック (ビューの操作またはさまざまなビュー コンポーネント間の対話に固有のロジック) のリポジトリでもある必要があります。また、ビジネス ロジックをイベントの動作にも関連付けます。

  3. ビジネス ロジックや DAO レイヤーに public static メソッドを使用することはありません。これは、自動化された単体テストには適しておらず、アプリが CDI や Spring などの依存性注入フレームワークを利用できなくなります。代わりに、BO と DAO のインターフェイスを作成してから、その実装クラスを作成します。

  4. その点については、CDI や Spring などの依存性注入フレームワークを利用してください :) これにより、ビジネス ロジック オブジェクトや DAO を ManagedBeans や単体テストに自動的に注入できます。また、アプリケーションの他のレイヤーのコードに結合することなく、実装または DAO を交換することもできます。

于 2012-09-13T17:25:06.543 に答える