Adam Bien Rethinking Business 層を読みました。OrderService などのサービス ファサードの作成について言及しました。ただし、大規模なエンタープライズ アプリケーションに多くのサービス ファサードを使用できますか。顧客モジュール、注文モジュール、輸送モジュールがあります。これらのモジュールをすべて含む 1 つの大きなファサードを作成するのではなく、高レベル モジュールごとにサービス ファサードを作成できますか。したがって、私の JSF 2.0 Web アプリでは、次のような呼び出しを行うことができます: transportServiceFacade.findDetails() orderServiceFacade.findDetails()
このようにする代わりに
genericServiceFacade.findDetails()
私の例ではむしろ多くのファサードを使用しています。これはパフォーマンスに影響しますか?
確かにできます。私はこの特定の本を知りませんが、Adam Bien がシンプルさとエレガンスの実践者であることは知っています。特に、EJB 2.x 時代に行われた Enterprise Java ソリューションと比較すると、これは素晴らしいことだと思います。しかし、彼が採用するシンプルさは、時には単純化しすぎていることもあります。お気づきかもしれませんが、システムが成長するにつれて、一般的なファサードを他のファサードに分割し、より専門化することがより理にかなっています。
これらの EJB もポーリングされるため、これがパフォーマンスに影響を与えることはありません。どちらかといえば、もう少し多くのメモリを消費することになりますが、通常は最初にアーキテクチャを気にし、次にパフォーマンスを気にする方が良いので、これについては心配しません. それでも、パフォーマンスは「私は思う」ではなく、「私は知っている」ものであるべきです (つまり、測定し、何かが実際にパフォーマンスに影響を与えていることを自分自身で証明します)。
ServiceFacase は単なるパターンであり、必要に応じて変更できます。ただし、ServiceFacade パターンの考え方は、単一コンポーネントの境界メソッドを 1 つの単一クラス (サービス ファサード) にグループ化することです。より個別のサービス ファサードが必要な場合は、さらに分離されたコンポーネントも必要になる可能性があります。
もう 1 つの提案は、フロントエンドの単一のアクションから 2 つの異なるファサードのメソッドを呼び出す場合、そのビジネス ロジックをファサードの 1 つの単一のメソッドにグループ化することをお勧めします。サービス ファサードは常にトランザクションを開始する必要があり、1 回のアクションでトランザクションの数を減らすことをお勧めします。理想的には 1 つのトランザクションに減らします。サービス ファサードは、他の方法ではなく外部からコンポーネントにアクセスするクライアントのニーズに合わせて設計する必要があります。