8

セッション ファサード コア J2EE パターンの長所と短所は何ですか?

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

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

4

4 に答える 4

6

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

具体的には、Session Facade を使用すると、Session EJB を使用してビジネス ファサードとして機能します。これは、すべての J2EE サービス (認証/承認、トランザクションなど) を利用できる良い理由です...

それが役立つことを願っています...

于 2008-09-18T00:13:43.530 に答える
0

Rod Johnsonは、Session Facadeを使用する主な理由は、コンテナー管理のトランザクションを実行している場合であると主張しています。これは、最新のフレームワーク（Springなど）では必要ありません。

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

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

于 2008-09-21T23:31:47.797 に答える
0

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

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

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

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

于 2008-09-18T23:16:40.163 に答える
0

J2EE に関連することについて話すときはいつでも、舞台裏には常にたくさんの仮定があり、人々はそれを何らかの形で仮定しており、混乱を招くようです。（おそらく、質問もより明確にすることができたでしょう。）

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

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

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

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

Rod Johnson は次のように書いています。適切なコロケーション オブジェクト モデルの上にリモート ファサードを実装することで、必要に応じてリモート クライアントにサービスを提供します。」(Johnson, R「EJB を使用しない J2EE 開発」p119。)

(c) EJB 仕様 (および特にセッション ファサード コンポーネント) が、優れた設計の展望を台無しにするものであると考えていると仮定すると、次のようになります。

Rod Johnson は次のように書いています。「一般に、Spring アプリケーションでローカル SLSB を使用する理由はあまりありません。Spring は EJB よりも優れた宣言型トランザクション管理を提供し、CMT は通常、ローカル SLSB を使用する主な動機です。したがって、 EJB レイヤーはまったく必要ないかもしれません。" http://forum.springframework.org/showthread.php?t=18155

Web サーバーのパフォーマンスとスケーラビリティが主な関心事であり、コストが問題である環境では、セッション ファサード アーキテクチャはあまり魅力的ではないように見えます。データベースと直接対話する方が簡単な場合があります (ただし、これは階層化に関するものです)。

于 2008-09-22T02:06:01.093 に答える