|
||||||||||||
| 1 2 3 4 次のページ | ||||||||||||
| はじめに | ||||||||||||
|
第2回ではPOJOでWebアプリケーションを実現するDIxAOPコンテナについて紹介します。今回紹介する「Seasar2」「Spring」「PicoContainer(NanoContainer)」「HiveMind」「Geronimo」の状況は表1のようになっています。 |
||||||||||||
|
DIxAOPコンテナの位置づけは「第1回:Webアプリケーションフレームワークの比較」で紹介したように、オブジェクト間の依存性を解消するものです。これらのDIxAOPコンテナは、前回紹介したWebフレームワークや次回紹介するO/Rマッピングフレームワークとは少し異なっています。 DIxAOPコンテナは単体で使用することがあまりなく、既存のフレームワークと組み合わせて使用する場合か、ビジネスロジックをPOJOで開発してコンポーネントの再利用を考慮してシステム開発を行う場合の2点において威力を発揮します。 DIxAOPコンテナの役割は、既存のフレームワークで作成したオブジェクトとビジネスコンポーネント、もしくはビジネスコンポーネント同士の依存関係を疎結合にし、システム開発を効率的に行っていくためのものです。 それでは、実際のDIxAOPコンテナについて紹介します。 |
||||||||||||
| DIとは | ||||||||||||
|
DI(Dependency Injection)とはオブジェクト間の依存関係を疎結合にし、POJOでアプリケーションを構築するためのデザインパターンです。 ![]() 図2:DIの構図 DIを使う以前の開発では、オブジェクト間の関係は「new」演算子を用いていたためオブジェクト同士が依存していました。しかしこれではコンポーネントの再利用を考えた場合、コードに依存しているコンポーネントは再利用することができません。それに対してDIでは、外部ファイルやアノテーションを使うことで、オブジェクトの依存関係をPOJOで開発したオブジェクトに対して注入することができるため、オブジェクト間の依存関係を疎結合にできるわけです。 開発者にとってDIを使うことのメリットはやはりテストになります。DIを使うことでオブジェクト間の依存関係は外部ファイルに記述されるので、テスト用にソースコードを変更しなくても依存関係を持ったオブジェクトをテスト用のモックオブジェクトに切り替えるだけでテストを行うことできます。 |
||||||||||||
|
1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||



