Core J2EE Patternsを読みながらの超適当メモビジネス層のパターン

そんなこんなで続きー。
今日は7章を制覇（流し読み）するぞー　(`･ω･´)

Business Delegate

Delegateって名前ついてるけど、Facadeの一種かなぁ。
どちらかというと分散ネットワーク上のどっかにいるFacadeを利用する際の、ローカル向けFacadeな感じがする。
ネットワーク例外をアプリケーション例外にしたい、とかってあたりもろにそうっぽぃ。
何かしようとするたびにRMI周りの例外のTryCatchとかやってたら発狂できるもんなぁ・・・

これを使う事でプレゼンテーション層と実際のビジネスロジックを実行するビジネス層（ネットワークのあっちにいるかも）なのと疎結合に出来るのと必要に応じてキャッシュする事でパフォーマンスの最適化が図れるのが一番のメリットかな。

Service Locator

ものすっごいDIコンテナの先祖っぽい雰囲気がする！
責務的にはめちゃ大変な人で、JNDIやらJMS関係のLookupからそれで取得したオブジェクトから生成するオブジェクトの管理やらやらやる事もっさり。
ここら辺のぐっちゃり具合から、とりあえずインスタンス管理だけやらせようぜ、みたいになったのがIoCコンテナの先祖になるのかな？
とりあえず、複雑なオブジェクトグラフのオブジェクトでも　あれが欲しい　って言うだけで取り出せるって所は同じ考え方ですね　(*´¬`)

Session Facade

なにやらここら辺のパターンは理想と現実の戦いな感じがする。
分散環境に色々実行できる口があったら、色々な事ができるんじゃ！　→　密結合しすぎて身動きとれなくねぇ？　→　んじゃ一枚挟もうか・・・　みたいな。
しかもさらにこいつにBusiness Delegateが被さるんだからなぁ、そりゃ複雑にもなるよ。。。　(´･ω･`)
こいつもやりたい事は内部にたくさんいるBusiness Componentの複雑な関係や振る舞いを隠蔽する事。
ここら辺の概念をネットワークのあっちとこっち、みたいに分割してあるのがJ2EE系のパターンなのかな。

Application Service

うーむ、Session Facadeとの差が今一わからず。
住み分けとしては、インターフェイス層がSession Facadeで、それに対応するインフラストラクチャ層がApplication Serviceらしい。
雰囲気としては、アプリケーション特有の振る舞いをApplication Serviceとして実装して、これらの組み合わせをSession Facadeでする感じかなぁ。
そうする事により、振る舞いの部品化が促進される　はず　だから再利用性もたかまるし、Session Facadeは部品を組み立てるだけだから良いでしょ？みたいな。
実際問題どこまで上手くいったのか疑問だけど・・・

Business Object

DDDで言う所のドメイン層なのかな？
本来的にやりたいビジネスロジックやらそれにまつわる永続化を担ってるっぽい。
ただ、この粒度だと細かすぎて実際に処理を依頼してくるクライアントと密結合になりすぎるからサービス層に相当する所でApplication ServiceやらSession Facadeやらを引っ張りだす事で、クライアントと密結合にならないようにしてる・・・って感じかな。
密結合をさけようとするあまりに階層が深くなりすぎてるような気がするけど、結合度を考えなかったとしても　リモート呼び出し　するかもしれない所で細かすぎるやり取りを毎度毎度してたらパフォーマンスが出ないんだろうな　(´･ω･`)

ちなみにビジネスに関係ない所（医療とか整備とかとか）でこの概念を表す場合は　ドメインオブジェクト　と言うらしい。
・・・最初から全部ドメインオブジェクトっていっとけばよかったんじゃ　（コラ

Composite Entity

Business Objectの実装方法なのかな？
EJB1.1時代はEntityBeanをリモートオブジェクトの形で実装する必要があったから、とりあえず何か処理させようとしたらリモートオブジェクトを作らないと駄目だけど、かといって処理を全部リモート呼び出しでやってたらたまったもんじゃないから外側に見える親はリモートオブジェクトとして作って、裏側にPOJOで細々とした処理を行ってくれる人を作ればいいんじゃね？みたいな感じだったのかも。

Transfer Object

DXOの元なのかな？
異なる層でのデータのやり取りを行う際に、層をまたいでDBアクセスやらリモート呼び出しやらするかもしれんオブジェクトを渡すより、値を直接渡した方がいいじゃーんって感じに見える。
getなんたらを呼ぶ度にネットワーク間でやり取りとかし始めたら、相当重いだろうしなぁ　(´･ω･`)

Transfer Object Assembler

Transfer Objectを作ってみたのは良いけど実際問題として何かしらの処理をする際は色々な層からTransfer Object取得しないと行けないし、その取得用の処理ってTransfer Objectを作ってくれる人との密結合だよねーみたいな感じになっちゃって、それだとなんかイヤンだからTransfer Objectをまとめて組み立ててくれる人を作るか・・・みたいな雰囲気を感じる。
Transfer Object AssemblerはService Locatorとかを使って自身に必要なコンポーネントをかき集めて、一気にTransfer Objectの山をがつっと作ってクライアントに送ってやる・・・って動きになるのかな。
それによる利点はクライアントがいちいちTransfer Objectを組み立てなくても良いので、クライアントがTransfer Objectを作るために必要なBusiness Objectとかそこら辺と結びつく事がなくなるので密結合しなくなる事と、分散アクセスが減るのでパフォーマンスがアップする可能性がある、とかかな。
なんか考え方が重いな。。。

Value List Handler

毎度毎度もの凄い膨大な検索結果になる一覧を検索して、実際にはその一部しか使わなかったらもたいないし遅くね？という非常にありきたりな問題に対する解決策。
とはいえ、これを見る限り一度は膨大な検索結果をメモリ上にキャッシュする必要があるから、相当ブルジョワな物理メモリ領域が無い限りむりぽな悪寒。
これってサンプルソース見る限り検索結果を全部キャッシュできる事が前提になってるんですが、実際はもっとかっちょいい実装方法がとられてるのかなぁ。
全部キャッシュするの前提って結構厳しいよなぁ、検索結果が億単位であったらどうするんだろ。

そんなこんなで7章の流し読み終わりー
何となくの現状での感想としては、EJBは理想を追い求めて作った仕様に現実がさっぱり追いつかなくて、結局その理想と現実のギャップを埋めるためのパターンがいっぱい出てきて、その結果として複雑さばかりが増しまくってしまったんじゃないかっつー気がします (^^;