- PR -

Spring AOPによるトランザクション管理について

1
投稿者投稿内容
yuu-abe
会議室デビュー日: 2003/01/24
投稿数: 4
投稿日時: 2005-09-14 14:40
はじめて投稿させた頂きます。

現在、AOPを利用して、トランザクション管理の簡素化を狙っております。
書籍は、技術評論者「Spring入門」を参考にしました。

そこで、疑問が発生しました。

単一のDAOを実行し、コミットか、ロールバックを行うことは、
Springの明示的トランザクションで可能かと思いましたが、
複数のDAOの実行をひとつのトランザクションで管理し、
コミット、ロールバックを行えないように思えました。

AOPを利用してトランザクション管理を行う際に
複数のDAOでコミット、ロールバックを実行できるようにするには、
どのような思想が必要でしょうか？

従来どおり、F層（ビジネス層)でトランザクションを開始し、
D層（インテグレーション層）へ渡す方法しかないのでしょうか。

この方法ですと、F層⇔D層となり、F層⇒D層とはならないので、寂しい限りです。

AOPによるトランザクション管理の思想をご教授頂けないでしょうか？

以上　宜しくお願いします。
takashi
ベテラン
会議室デビュー日: 2004/02/12
投稿数: 79
お住まい・勤務地: 東京
投稿日時: 2005-09-14 15:39
はじめまして。

今月のWEB+DBプレス(vol.28)のJAVAグッドデザインバッドデザイン（だったような）という記事にちょうど同じような特集があったように思います。よかったら参照してみてください。

それで、
>複数のDAOの実行をひとつのトランザクションで管理し、
>コミット、ロールバックを行えないように思えました。
DAOの１メソッドごとにトランザクション管理しているとそうなりますね。

大概は、F層（これはファサード層の略でしょうか？）の1メソッドごとにトランザクションを管理するのが一般的ではないでしょうか？（例えばEJBでいうところのSessionBeanみたいな）

例えば、
コード:
// ビジネスロジック担当クラス
class SampleFacade{
  // UserDaoはインターフェース
  UserDao dao;
  
  public setDao(UserDao dao){
    this.dao = dao;    
  }
  
  public 〜 executeUpdate(){
    try{
      // ここからトランザクション開始
      dao.updateA(･･･);
      dao.updateB(･･･);
      dao.updateC(･･･);
      // ここまできたらコミット
    }
    catch(Exception e){
      // ロールバック
    }
  }
}


のような感じで、トランザクション開始・コミット・例外発生時にロールバックの流れをAOPでフレームワーク化してビジネスロジック内から排除すると簡素化できるような気がします。

あと、Light Weight Javaという書籍でSpringとHibernateの連携を扱ってますのでそれも参考になるかと。

>この方法ですと、F層⇔D層となり、F層⇒D層とはならないので、寂しい限りです。
これはDAOをインターフェースを介してDIでセットするようにするとかじゃだめでしょうか？

ずれてたらすいません。
以上お役に立てれば幸いです。
yuu-abe
会議室デビュー日: 2003/01/24
投稿数: 4
投稿日時: 2005-09-14 16:18
takashiさんありがとうございました。

>今月のWEB+DBプレス(vol.28)のJAVAグッドデザインバッドデザイン（だったような）という
>記事にちょうど同じような特集があったように思います。よかったら参照してみてください。

参考にさせていただきます。


＞大概は、F層（これはファサード層の略でしょうか？）の1メソッドごとにトランザクションを
＞管理するのが一般的ではないでしょうか？（例えばEJBでいうところのSessionBeanみたい
＞な）

やはりそうですか。従来からそのやり方を行っていました。
ただ、AOPを利用することによって　F層⇔D層　ではなく、F層⇒D層が可能と感じられました。

P層⇒F層⇒D層の完全な形を作成したいと思っています。
また、情報がありましたら、宜しくお願いします。


takashi
ベテラン
会議室デビュー日: 2004/02/12
投稿数: 79
お住まい・勤務地: 東京
投稿日時: 2005-09-14 17:13
やはりyuu-abeさんのやりたいこととはちょっと違ったみたいですね^^;

つまりは、従来の設計とは違う形で各層の依存性を完全な一方通行にしたいということでしょうか？
具体的にどういう設計でどう実現したいのか興味があります。

たとえば、F層のクラスがD層のクラスのインスタンスを保持して、F層からD層に引数を受け渡してD層のメソッドを呼ぶと、
F層⇒D層
という形で依存してるということですよね？

この場合D層のインスタンスは誰から引数を渡されたかは知らないので
F層⇔D層
とはならない気がするのですが、yuu-abeさんはどこの点をD層からF層への依存と考えてらっしゃるのですか？

逆に質問になってしまい申し訳ないですが、宜しくお願いします。
yuu-abe
会議室デビュー日: 2003/01/24
投稿数: 4
投稿日時: 2005-09-14 18:59
takashiさん　本当にありがとうございます。

>F層⇒D層
>という形で依存してるということですよね？

すみません。
最初に時点で、「⇒」の意味をしっかりと定義すべきでしたね。

今回の「⇒」の意味は、「知っている」または、「依存している」という意味です。

F層⇒D層の場合
D層にインタフェースの変更があった場合、F層は変更になります。

F層⇔D層の場合
D層にインターフェース部分に変更があった場合、F層は変更になります。
また、F層の実装によって、D層が変更される場合もあります。

今回は、F層がどのようなロジックになろうともD層が変更されることが無いように
設計をしたいと思い、F層へD層の依存を全く無くしたいわけです。


ということで、F層側からDBコネクションやトランザクションを渡すことはF層に依存しているように思えまして、
それをAOPを利用して完全に排除し、開発者の方には全く意識が無い状態にしようと思いました。

ただ、takashiさんとお話をしている中で、今回のSpringやSeasarを利用することで、
F層とD層は、値の受け渡しのみを行うこととし、
DBコネクションやトランザクションに関しては、AOPでの制御が可能であり、
D層開発者が、DBコネクションやトランザクションを意識する必要が無いことが
認識でき、「F層⇒D層」はできていると思えました。

takashiさん本当に貴重な時間をありがとうございました。


takashiさんの質問の回答になっているかが不安です。。。。



るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-09-15 02:20
るぱんです。

横槍ですいません。
気になったので。

Beanの形でDAOをプロパティに持つクラスを用意して、
アクションメソッドで全てのプロパティを管理する事を想定されています・・・？

D層とF層の間にコレを噛ませると、
DAO自体は影響は受けない・・・？

そんなことは言っていない・・・？(・_・？)ハテ
yuu-abe
会議室デビュー日: 2003/01/24
投稿数: 4
投稿日時: 2005-09-16 15:31
返信が遅くなりすみません。

＞Beanの形でDAOをプロパティに持つクラスを用意して、
＞アクションメソッドで全てのプロパティを管理する事を想定されています・・・？
＞D層とF層の間にコレを噛ませると、
＞DAO自体は影響は受けない・・・？

＞そんなことは言っていない・・・？(・_・？)ハテ

私が実現したいのは、F層からD層へ与える情報は、
検索のための情報のみで、DBコネクションもトランザクションも
渡す必要が無いように設計がしたいのです。

プロパティ化することで、何が実現でき、DAO自体に影響が
無くなるのでしょうか？

以上　宜しくお願いします。
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2005-09-17 15:53
プロパティ化する必要はなかったです。すいません。

DAOを一度作ってしまったら
手を入れたくないと言うのであれば、

もう一つ別にDAOを作成してしまえば良い・・・と言う発想です。

例えば、追加要件で項目が追加になりました・・・とします。
同じテーブルを見ていても、
別々のDAOで値をとってくるのようにすれば、
最初に作ったDAOは作り直さなくて良いのかな・・・と。

DAOを呼び出す側とDAOの間に一枚クラスを挟んでやれば良いのではないか
そんな風に考えました。


_________________
1

スキルアップ／キャリアアップ（JOB@IT）