 |
|
| DIxAOPコンテナ「Seasar2とSpring」
|
第３回：Seasar2の導入によるDIの実現
著者：豆蔵 長谷川 裕一、竹端 進 2005/11/16
|
|
|
| 前のページ 1 2 3 4
|
|
| トランザクションの設定
|
Seasar2の宣言的トランザクションは、AOPの機能を使用して実現されています。
今回のサンプルではトランザクションの対象となるメソッドを指定せず、Aspect可能なメソッドすべてを対象としました。対象を指定する場合はaspectタグ内にpointcutタグを指定することにより行えます。詳しい設定に関しましては、次回以降のAOPの回で解説いたします。
トランザクションは、トランザクション属性ごとに用意されたコンポーネントをAspectとして使用します（表6）。ロールバック対象の例外、非ロールバック対象の例外はメソッド"addCommitRule（）／addRollbackRule（）"により設定することができます。
表6：トランザクション属性 （画像をクリックすると別ウィンドウに拡大表示します）
また、Seasar2が標準で用意している定義ファイル"ejbtx.dicon"には、EJBのコンテナ管理トランザクション（CMT）と同じように実行時例外（java.lang.RuntimeException）、リモート例外（java.rmi.RemoteException）とその派生例外が発生した場合はロールバックし、そのほかの例外（java.lang.Exception）が発生した場合はコミットするコンポーネントが定義されています。
|
| トランザクション属性 |
コンポーネント名 |
| Required |
ejbtx.requiredTx |
| RequiresNew |
ejbtx.requiresNewTx |
| Mandatory |
ejbtx.mandatoryTx |
| NotSupported |
ejbtx.notSupportedTx |
表7：EJB互換のトランザクションコンポーネント
|
| 自動バインディング
|
Seasar2におけるコンポーネントの依存関係は、設定対象がインターフェースの場合、DIxAOPコンテナが自動的に解決します。この方法がデフォルトの設定になっています。
サンプルでは、EmployeeManagerImplが要求するEmployeeDaoインターフェースを実装するコンポーネントはEmployeeDaoImplだけです。そのため、設定ファイルにインジェクション対象を設定することなくEmployeeManagerImplが取得できます。
この判断は定義ファイルごとに行われますので、定義ファイルのインクルードの順序に意味があります。
例えば"first.dicon"と"second.dicon"の2つの定義ファイルにあるインターフェースを実装したコンポーネントが1つずつ含まれるとします。この時、インクルードの順序が"first.dicon"、"second.dicon"の場合、インジェクションの対象は"first.dicon"に定義されたコンポーネントになります。また、1つの定義ファイルにコンポーネントが2つ含まれる場合、Seasar2は自動バインディングできないため、インジェクション対象を指定する必要があります。
|
| Seasar2のDIまとめ
|
今回はSeasar2を使用してインターフェースベース設計と宣言的トランザクション管理を導入しました。サンプルのアプリケーションはAADL1から大幅に柔軟度を増しています。
Seasarファウンデーションのモットーとして「システム構築の現場にもっと『易しさ』と『優しさ』を」という言葉があります。Seasar2のDIは、この『易しさ』と『優しさ』を実現するために、定義ファイルへの記述内容をなるべく少なくするようにしています。
その機能の1つが自動バインディングです。「コンポーネント間の依存関係が明確であり記述する必要がないなら、あえて書くことはない」という考え方です。
また、定義ファイルについても1つのファイルにまとめてしまうとシステムが大規模化するにしたがい管理が煩雑になります。この場合には、パッケージごとに定義ファイルを作成するなどの一定のルール（規約）に基づいた方法が推奨されています。使用者はルールにしたがって使用するパッケージの定義ファイルをインクルードすることで全体を構成します。これも『易しさ』と『優しさ』の一環です。
これに対してSpringでは定義ファイルにコンポーネント間の依存関係を明示することでDIxAOPコンテナの管理する範囲を明確にします。これによりシステム構築の場において開発を進めやすくしています。
筆者は最初、Seasar2の定義方法を「ゆるい」と感じ、ある意味Seasar2の自由な方針が心配でした。Springのようなきちっとした定義方法に慣れていたこともありますが、「ゆるさ」が間違いにつながったり、また全体の見通しが悪くなったりするのではないかと不安だったのです。
しかし、Seasar2の定義方法で大事なのは自由をどこまでいかすか、そしてその自由をどこまで保てるかです。いいかえると「ルール（規約）を決め、そのルールを守ること」が大切なのです。
確かにSeasar2でもSpringのようなガチガチな定義方法も可能です。しかしSeasar2のよさは若干損なわれてしまいますが…。
次回の連載では、SpringのDIをサンプルを使用して解説していきます。Seasar2との違いを認識し、プロダクトの特徴を体感してください。
|
前のページ 1 2 3 4
|
|
|
|
|
著者プロフィール
株式会社豆蔵 長谷川 裕一
XMLの技術開発やCORBA、EJBを使用したシステム開発などを経て、現在はアジャイル開発プロセスの導入から工学的なソフトウエアプロセスの策定、オープンソースプロダクトに関するコンサルタント、アーキテクトとして常に第一線で活躍。共著として「プログラムの育てかた 現場で使えるリファクタリング（ソフトバンク）」、「Spring入門（技術評論社）」。
|
|
著者プロフィール
株式会社豆蔵 竹端 進
鉄鋼系SIerを経て現職に。現在はオープンソースプロダクトに関するコンサティング、開発支援、教育を行うチームに所属。日々、新たな技術をどのように生かしていくかを考える毎日。現在の注目対象はSeasar2とMaven。
|
|
|
|
|
|
