|
||||||||||||
| 前のページ 1 2 3 4 次のページ | ||||||||||||
| 宣言トランザクション管理 | ||||||||||||
|
さらに、EmployeeManagerImplを見ていくとcommitやrollbackなどのトランザクションを管理している部分が消えていることがわかると思います。 ソースコードに明示的にコーディングしていたトランザクション管理をSeasar2に移して、宣言的なトランザクション管理を行っているからです。 |
||||||||||||
| TransactionManagerの設定 | ||||||||||||
|
リスト5はサンプルのコンポーネント定義"j2ee.dicon"から抜粋した、トランザクション管理機能を持つTransactionManagerの設定部分です。 リスト5:TransactionManagerの設定 |
||||||||||||
<component name="transactionManager"
|
||||||||||||
|
リスト5は以下の3つの設定で構成されています。
表1:TransactionManagerの設定の構成 |
||||||||||||
| トランザクション管理の設定 | ||||||||||||
|
トランザクション管理を行うために、サンプルではSeasar2が提供するRequiredInterceptorクラスを使用しています。このクラスをAspectとして組み込むことでトランザクション機能を実現しています。 リスト6は、サンプルの定義ファイル"app.dicon"から抜粋したトランザクション管理の設定部分です。"requiredTx"とは"j2ee.dicon"ファイルで定義されているコンポーネント名です。 リスト6:宣言的なトランザクションの設定 |
||||||||||||
<component class="jp.co.thinkit.employee.business.EmployeeManagerImpl">
|
||||||||||||
|
クライアントがEmployeeManagerのメソッドを利用するごとに、Seasar2はAspectから呼び出されるTransactionManagerを使用してトランザクションを開始し、その後にEmployeeManagerImplの該当メソッドを呼び出します(リスト7)。メソッドの終了後は、同様にAspectから呼び出されるTransactionManagerを使用してトランザクションをコミットします。 リスト7:EmployeeManagerの呼び出し |
||||||||||||
employeeManager.addEmployee(emp);
|
||||||||||||
| 現在のAADL | ||||||||||||
|
さて、ここまでで今回のSeasar2を利用したEmployeeManagerImplと連載1回目のEmployeeManagerImplを比較してみましょう。 インターフェースベース設計と宣言トランザクションを導入したEmployeeManagerImplがEmployeeDaoインターフェースの実装をまったく意識しないことがわかります。Seasar2を利用することでオブジェクトの管理(生成など)、構成(関連の設定など)処理をコンポーネントから排除することができています。つまりレイヤー間のコンポーネントの疎結合が実現でき、コンポーネント間が疎結合になったときの利点(表2)が享受できます。
表2:コンポーネント間の疎結合の実現による利点 また、トランザクション管理をDIxAOPコンテナに移すことでEmployeeManagerImplは完全なPOJOとなり、各種のコンテナやJDBCなどのDBアクセス関連のオブジェクトにさえ依存していないことがわかります。よってメンテナンスや再利用性の向上が可能になり、新機能の追加が容易になっています。 AADLの表3と見比べてみるとAADL2以上となりAADL3にほぼ合致することが確認できると思います。 |
||||||||||||
|
前のページ 1 2 3 4 次のページ |
||||||||||||
|
|
||||||||||||
|
|
||||||||||||
|
||||||||||||
|
|
||||||||||||
|
||||||||||||



