以下を使用したソリューションの、適切で実用的だが単純なパターンとして何を提案しますか。
また、永続化のために DAO の独自のレイヤーを使用する必要がありますか? JPA を使用してオブジェクトを DB に永続化します。
EJB からビジネス ロジックを撤回する必要がありますか? すべてのオンライン情報源は私に異なることを教えてくれ、私を混乱させます...
私なら間違いなくビジネス ロジックを Stateless Session Beans に入れます。ステートレス セッション Bean は、トランザクション境界を適切にキャプチャするので優れています。また、ビュー レイヤーをパーシスタンス レイヤーから切り離します。
SSB のメソッドが、ユーザーが達成したい中小企業の目標に対応するように注意してください。
もう 1 つのポイントは、返すデータにオブジェクト ツリー内のすべてのデータが含まれていること、および残りを取得するために遅延読み込みに依存しないことを確認する必要があることです。これはあらゆる種類の問題を引き起こすためです。
ステートフル セッション Bean からできるだけ離れてください。これは悪いニュースであり、Web アプリケーションのコンテキストでは壊れた概念です。
長時間実行する場合は、JMS メッセージを送信してトリガーするメッセージ駆動型 Bean の使用を検討してください。これらは、ビジネス ロジックをより迅速に解放し、トランザクションをより短く保ち、エンド ユーザーに制御をより迅速に返すバックグラウンド処理を行うための優れた方法です。
JSP/サーブレット+ EJB + MySQLを使用したソリューションの、実用的でシンプルなパターンとして何を提案しますか?
選択した MVC フレームワーク、ビジネス ロジックとトランザクション管理用のステートレス セッション Beans (リモーティングが必要ない場合はローカル インターフェイスを優先)、永続化用のエンティティを使用します。
可能な限り EJB を注入します (Java EE 6 を使用している場合、これは任意の場所を意味し、インターフェイスをスキップすることもできます)。
また、永続化のために DAO の独自のレイヤーを使用する必要がありますか? JPA を使用してオブジェクトを DB に永続化します。
はいと言う人もいるかもしれませんが、ほとんどの場合、私はいいえと答えます。は既にドメイン ストアEntityManagerパターンを実装しているため、単純なニーズのために DAO の背後にシールドする必要はありません。
これに関するその他の意見については、次のリソースを参照してください。
EJB からビジネス ロジックを撤回する必要がありますか?
私はしません。ビジネス ロジックを (ステートレス) セッション Bean に入れます。EJB3 は POJO であり、簡単にテストできます。ビジネス ロジックを別のレイヤーに委譲する必要はありません。
Anno 2012 プレゼンテーション層としてサーブレットと JSP を使用することはお勧めしません。これは 2002 年に大流行しましたが、それは 10 年前のことです。
現在、Java EE には、JSF と呼ばれる優れた MVC フレームワークが組み込まれています。代わりにこれを使用する方がはるかに優れています。ほとんどの場合、コンポーネント ライブラリ PrimeFaces からいくつかのウィジェットをフェッチする必要があります。これは、すべての標準ウィジェットが少し基本的なものだからです。OmniFaces のようなユーティリティ ライブラリも優れた追加機能です。
DAOについて; (JSF) バッキング Bean でエンティティ マネージャーを直接使用するところまでは行かないでください。ただし、既にビジネス ロジックにサービス クラス (トランザクション境界) を使用している場合は、DAO を使用するのもやり過ぎかもしれません。
dao.findByName(...) は、名前付きクエリをロードし、パラメーターを設定し、(単一の) 結果を取得するよりも少し明確に見えるなど、DAO にはまだいくつかの小さな利点がありますが、コストは、おそらく一部のサービスに加えて、エンティティごとに個別のDAOを維持します。