0

私のユースケースは次のとおりです。

注文明細、顧客、および支払いの詳細を使用して注文を管理します。

このアプリは、既存の注文を編集したり、新しい注文を作成するために注文の詳細ビューを開くことができる注文リスト ビューで構成されています。注文の詳細ビューはビュー パラメーターを使用します (既存の注文 ID、または作成される新しい注文を示すものは何もありません)。

注文詳細ビューが開かれると、OrderControllerBean が ConversationalScope を開始し、注文 ID の可用性に応じて新しい注文エンティティをロードまたは作成します。この Bean はステートフル セッション Bean であり、ファサードとして使用することを意図しています。この Bean には、注文明細、顧客、および支払いの詳細を処理するためのメソッドと、注文を保存および削除するためのメソッドが含まれています。これらのメソッドは、ある種の DAO としてステートレス セッション Bean として設計された注入された EJB を使用して、JPA エンティティの注文、注文明細、顧客、および支払いの詳細を処理します。

ユーザーは、顧客情報、支払い情報、および注文明細リストを含む注文詳細ビューから、注文明細を追加/編集する注文明細詳細ビューと、同様の方法で顧客および支払い詳細ビューに移動できます。これらの詳細ビューはすべて同じ OrderControllerBean を使用します。顧客、注文明細、および支払いの詳細ビューには、トランザクションではない [OK] ボタンと [キャンセル] ボタンがあります。

注文の詳細ビューには、会話中に行われたすべての変更を保存する [保存してキャンセル] ボタンがあります。

私が今持っている質問は、このデザインは適切で大丈夫ですか?

次の問題についてはよくわかりません。

ユーザーが保存またはキャンセルを使用しなかった場合はどうなりますか?

変換またはセッションがタイムアウトするまで、すべてが維持されますか? これはトランザクションの観点から何を意味するのでしょうか? これは、管理対象エンティティにとって何を意味しますか? ユーザーが職場を離れ、後で会話の作業を続けて戻ってきた場合はどうなりますか? 会話がタイムアウトした場合、この問題を適切に処理するにはどうすればよいですか?

4

2 に答える 2

0

注文を作成する際に、どちらかまたは両方の状況を評価する必要があるのはなぜですか? ポップアップフォームを起動する新しい注文と、おそらく「注文の詳細を表示」というデータテーブル行からの別のボタンがあります。デザインはいいです。ほんの少しの微調整。

  1. Visitすべてのセッション関連の資料を格納する単一のセッション スコープ オブジェクト (と呼びます) を作成して維持する必要があります。http セッションに依存し、コンテナーによって効果的に管理できる JSF セッション スコープ Bean を使用することをお勧めします。JSF セッション スコープ Bean は単純なオブジェクトとして http セッションに格納されるため、JSF のコンテキスト外で簡単に操作できます。ただし、CDI セッション スコープ Bean は、CDI の外部で処理するのが難しいです。
  2. <ui:include/>また、注文作成プロセスを、動的に読み込まれるページ フラグメントまたは細かいプライムフェイス ウィザードコンポーネントを使用して複数ステップのプロセスに分割することもお勧めします。複数ステップの作成では、ステップに沿ってデータを収集し、DTO のすべてのステップから必要な情報がすべて揃ったときにのみトランザクションをコミットするだけで済みます。タイムアウトの場合にコンテナーがクリーンアップできるように、ウィザード DTO を単一のセッション オブジェクトに保持します。ユーザーが保存もキャンセルもデスクから離れることもなかった場合、セッションは自然に終了します。そして、時間内に戻ってきて取引を続けることができます。カルロスが何に反対しているのかわからないステートレス セッション Bean ですが、私の経験では、Web サービスやメッセージ ターゲット(JEE5)などの他の方法で機能を公開できるという点で、ビジネス プロセスを公開する良い方法です。とりわけ、可能な限り多くのビジネス処理をマネージド Bean から除外し、EJB や Spring Bean などの耐久性のある構造に保持することは非常に優れた設計です。
于 2012-09-14T01:24:15.733 に答える
0

私の意見では、ステートフル Bean は苦痛であり、問​​題の原因です。

この責任をアプリケーション サーバーに任せるのではなく、http セッション レベルでタイムアウトを処理する方が適切です (特に、http セッション タイムアウトは依然として関連しているため、別のタイムアウトを追加するだけです)。

ステートフル Bean によって提供される永続的な状態をある種のオブジェクト キャッシングに置き換えることができます。または、データベースにセッション ID を追加して、そこでオブジェクトの状態を追跡することもできます (保存または保存されるまで一時オブジェクトを保持する特別なテーブルにすることができます)。たとえば、破棄されます)。

全体として、物事を分離し、Web サーバー側でタイムアウトと一時オブジェクトを保持し、ejbs を永続化 (JPA) およびファサード (ステートレス Bean) として使用します。

于 2012-09-13T21:13:06.897 に答える