Session Façade Core J2EE パターンの長所と短所は何ですか?

https://stackoverflow.com/questions/88833

01-07-2019
|

質問

その背後にある仮定は何ですか?

これらの仮定は特定の環境で有効ですか?

解決

セッションファサードは素晴らしいパターンです。実際には、ビジネスファサードパターンの特定のバージョンです。そのアイデアは、ビジネス機能を TransferMoney()、Withdraw()、Deposit() などの個別のバンドルに結び付けることです。そのため、UI コードは、低レベルのデータアクセスや、考慮する必要のないその他の詳細ではなく、ビジネスオペレーションの観点からアクセスします。

特にセッションファサードでは、セッション EJB を使用してビジネスファサードとして機能します。これにより、すべての J2EE サービス (認証/認可、トランザクションなど) を利用できるようになります。

お役に立てば幸いです...

他のヒント

Session Facade パターンの主な利点は、J2EE アプリケーションをビジネス機能ごとに論理グループに分割できることです。セッションファサードは、UI から POJO によって呼び出されます (つまり、ビジネスデリゲート)、適切なデータアクセスオブジェクトへの参照を持っています。例えば。PersonSessionFacade は PersonBusinessDelegate によって呼び出され、その後 PersonDAO を呼び出すことができます。PersonSessionFacade のメソッドは、少なくとも CRUD パターン (作成、取得、更新、および削除) に従います。

通常、ほとんどのセッションファサードはステートレスセッション EJB として実装されます。または、トランザクションに AOP を使用している Spring 環境にいる場合は、トランザクションマネージャーのすべての結合ポイントとなるサービス POJO を作成できます。

SessionFacade パターンのもう 1 つの利点は、ある程度の経験を持つ J2EE 開発者であればすぐに理解できることです。

SessionFacade パターンの欠点:これは、J2EE 1.4 仕様の制限によって制約される特定のエンタープライズアーキテクチャを前提としています (これらの批判については、Rod Johnson の書籍を参照してください)。最も有害な欠点は、必要以上に複雑なことです。ほとんどの企業では ウェブ アプリケーションの場合、サーブレットコンテナが必要になります。Web アプリケーションのストレスのほとんどは、HttpRequest またはデータベースアクセスを処理する層に発生します。したがって、サーブレットコンテナを EJB コンテナとは別のプロセス空間にデプロイすることは価値がないと思われます。つまり、EJB へのリモート呼び出しは、利益よりも苦痛を生み出します。

Rod Johnson 氏は、セッションファサードを使用する主な理由は、コンテナー管理トランザクションを実行している場合であると主張しています。これは、より新しいフレームワーク (Spring など) では必要ありません。

ビジネスロジックがある場合は、それを POJO に入れてください、と彼は言います。(私もこれに同意します。セッション EJB を実装するよりも、よりオブジェクト指向のアプローチだと思います。)http://forum.springframework.org/showthread.php?t=18155

対照的な議論を聞けてうれしいです。

J2EE 関連のことについて話すときは常に、舞台裏で大量の仮定が存在し、人々は何らかの形でそれを仮定しており、それが混乱につながるようです。（質問をもっと明確にすることもできたかもしれません。）

(a) EJB 仕様を通じて厳密な意味でコンテナ管理トランザクションを使用したいと仮定すると、

セッションファサードは、低レベルのデータベーストランザクションを抽象化し、より高レベルのアプリケーショントランザクション管理を提供できるため、良いアイデアです。

(b) がセッションファサードの一般的なアーキテクチャ概念を意味していると仮定すると、

サービスと消費者を分離し、その上にフレンドリーなインターフェイスを提供することは良いアイデアです。コンピューターサイエンスは、「間接的な層を追加する」ことで多くの問題を解決してきました。

Rod Johnson 氏は、「リモートインターフェイスを備えた SLSB は、RMI 上に構築された分散アプリケーションに非常に優れたソリューションを提供します。ただし、これは少数派の要件です。経験上、要件によって強制されない限り、分散アーキテクチャを使用したくないことがわかっています。適切に配置されたオブジェクトモデルの上にリモートファサードを実装することで、必要に応じてリモートクライアントにサービスを提供することができます。」 (Johnson, R「EJB を使用しない J2EE 開発」p119)。

ロッド・ジョンソンは、「一般的には、SpringがEJBよりも有能な宣言的トランザクション管理を提供するため、SpringアプリケーションでローカルSLSBをまったく使用する理由はあまりありません。CMTは通常、ローカルSLSBを使用する主な動機です。したがって、EJB 層はまったく必要ない可能性があります。」 http://forum.springframework.org/showthread.php?t=18155

Web サーバーのパフォーマンスとスケーラビリティが主な懸念事項であり、コストが問題である環境では、セッションファサードアーキテクチャはそれほど魅力的ではありません。データベースと直接通信する方が簡単になる可能性があります (ただし、これは階層化に関するものです)。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow