Spring入門 第1章 Webアプリケーション概論 - お勉強メモ

CGIの問題点

• 処理要求のたびにプログラムが起動されること
• セッション管理がない
• ページの生成ロジックとビジネスロジックを分離するのが困難
  

→処理要求が多いときのパフォーマンス劣化やトランザクション管理の難しさにつながる

→JSP・Servletが登場

• JSP・Servletはマルチスレッドで実行され、実行基盤であるwebコンテナは勝手にセッション管理を行ってくれる。
• JSPページで生成を行いビジネスロジックをServletで行える

---

EJB(Enterprise　JavaBeans)の登場と衰退
　　EJBコンテナによってできること

• 分散して存在するEJBコンポーネントをあたかも同一マシン上に存在しているかのようにアクセスする
• 分散して存在するデータベースのトランザクションをあたかも1つのDBしかないようにトランザクション制御する。

EJBはもともと分散環境の為のコンポーネントとして登場した。だからJSPやServletといったWebアプリケーションのための技術ではなかった。
で、EJBはいつのまにか「再利用可能なコンポーネント」とか「SQLの記述が不要なDBアクセスフレームワーク」になってしまった。。

前回のEJBの問題点プラスこんな問題点も。

• EJBはもともと分散用のコンポーネントなのでリモートアクセスしかない→Webアプリケーションでは分散処理はめったにつかわないからローカルアクセスがしたくなる
• EJBコンテナに依存しているEJBはテストがしにくい

でももうちょっとしたらEJB3.0が登場する。
「SQLの記述が不要なDBアクセスフレームワーク」に近いものとして再登場。

---

DIコンテナ
アプリケーションが自らnewしなくてもアプリケーションが必要なobjをコンテナが勝手にobjのプロパティまで設定してくれた状態でアプリケーションに設定してくれる。

J2EEはちょっと重過ぎる→軽量コンテナの登場
軽量コンテナとは
POJO(PlainOldJavaObject)と呼ばれる普通のオブジェクトのライフサイクルの管理や、オブジェクト間の依存関係の解決を行うアーキテクチャを実装したコンテナ。

代表的な軽量コンテナ

• Spring
• PicoContainer
• Seasar
• HiveMind

など。

軽量コンテナ
IoC(Inversion　of　Control)
「制御の逆転」
「ハリウッド原則」
→IoCからDIコンテナに言い換えられるようになる。

DIコンテナの基本的な機能

• オブジェクトのインスタンス生成や、Singletonオブジェクトとしての提供などライフサイクル管理機能
• オブジェクト間の関連の制御を行う機能
• JavaコードやXMLなどで定義された設定コードを読み込みオブジェクトのライフサイクル管理や、オブジェクト間の関連を解決する機能
  

Singleton：アプリケーション全体で、唯一のオブジェクトを生成するパターンを意味します。

---

Aspect　Injection
Springのような高機能DIコンテナは宣言的に横断的な関心ごと（ログ出力や例外処理など）をPOJOに対して注入することができる。←Aspect　Injection(AI)

アスペクト指向
子供(Object)
特殊なプレート(Aspect)
お母さん(DIコンテナ）

子供は遊ぶことが仕事、宿題はしたくない。
なのでお母さんのおなかの中にいる子供の脳に特殊なプレートを転送して埋め込む。
埋め込まれた子供は「あそぼー」のメッセージを受け取ると脳に仕込まれた特殊なプレートが動き出し、そのプレートから触角状の手がでてきて宿題をはじめる。
おわるとなにごともなかったかのように子供はあそびに出かける。

AIとはお腹の中の子供に特殊なプレートを埋め込むこと。

---

EJBの後継として
高機能DIコンテナはEJBの利点である宣言的なトランザクション管理をAIを利用することによってPOJOで実現することが可能。
DBアクセスはO/Rマッピングフレームワークを利用すればよい。

EJBのかわりにDIコンテナを利用する最大の理由
DIコンテナに載せることが可能なオブジェクトがPOJOと言われる普通のJavaオブジェクトということ。
EJBコンテナに依存したEJBコンポーネントはユニットテストが行いにくいなどの問題点あり。

DIコンテナに管理されているPOJOはDIコンテナに依存してないから単体テストがしやすい。