設定を書きたいのか、書きたくないのか。その３

id:da-yoshi:20051021#1129853069の続きです。
後一件、考えてて気が付いたことがあるんで書いてみました。

自分はトランザクションのアスペクトについて、アノテーションで宣言する方が好きだと書いたのですが・・・どうも、現在の仕事の要件に引きづられて、そういう考えになっていた気がしてきました。
業務要件はあまり書きたくないので単純なことだけ言うと、今の仕事では、数万件のデータを１件ずつ処理して、その１件毎にトランザクションを確定させるようなシチュエーションが多いです。

	public void insertList(List<Hoge> hogeList) {
	
		for (Hoge hoge : hogeList) {
			try {
				insert(hoge);
			} catch (Exception e) {
				// エラー処理
			}
		}
		
	}
	
	@Transaction(TransactionType.RequiredNew)
	public void insert(Hoge hoge) {

		// INSERT処理

	}

}

簡単に書くとこんなかんじで、for文でクラス内のメソッドを呼んで、そのメソッドに対してRequiredNewトランザクションをかけてます。テストをするときにS2Unitの自動ロールバックの恩恵が受けられない（テスト用に設定を変えておけば大丈夫ですが）ので、あまりイイかんじじゃないのですが・・・ちなみに、同一クラス内からアスペクト対象メソッドを呼んでるので、この時点でSpringは検討対象から外れました（クラスを分ければ済む話なんでしょうけど、制限は少ないに越したことはないので）。また、insertメソッドはトランザクションの為に用意してるようなものなので、インターフェイスの方には敢えて記述したくない。そもそも本当はpublicで指定したくないようなメソッドなので。そうなると「インターフェイスに定義されたメソッド」という、自動アスペクト設定の要件から外れてしまいます。
まぁこういう要件なので、ちょっと作る側に注意してもらう必要があるかな？と思いまして、「このメソッドを呼ぶと、メソッド内処理についてはトランザクションが確定してしまう」ということを明記するという意味でも、アノテーションによる記述が有効かなと思っていました。ですが・・・まぁこれって、よくよく考えればそんなに使うシチュエーションじゃないですよね。
かつて、実装担当として、にっくきEJBに散々な目に遭わされた経験があるのですが（今思えば、EJBのせいというよりその適用方法が根本的に間違ってたんだけど・・・）その頃作ってたSessionBeanで、メソッド毎にトランザクション定義することって、まず無かった気がするし。大体はクラス全てのメソッドにREQUIREDの設定して完了だった気がします。そう考えると、ご指摘を受けた「明示的なトランザクショナルオブジェクトにメソッドレベルでわざわざ更に明示的なトランザクション指定を行うのは無駄」という状況は、たしかに多くの場合に当てはまる・・・っていうか、普通の開発要件だったらまずそうでした（汗）
ただ・・・まぁせっかく妙なことを口走った手前、極力プラス方向に考えると・・・基本的な設定（基盤のファイル設定だったり、規約による設定だったり）の補助としてのみアノテーションを位置づけるだけではなく、こういう「明示的に記述したいシチュエーションの為にアノテーションを利用する」という方向で考えれば、より有効な利用方法に繋がるんじゃないかという気がします。ちなみに、自分が考えたアノテーションによるアスペクトの定義には、このトランザクション以外にセキュリティがありました。セキュリティ情報を表すアノテーションをメソッドやクラスにつけて、その実行に必要なロールをenum等で定義してアノテーションに渡してやれば、実行時にユーザー情報からユーザーのロールを取得して簡単にチェックできるし、その機能を色々なクラス・メソッド単位で定義できるし、ソースを見ればそのクラス・メソッドの実行可能なロールも分かるし・・・いろいろ便利かなぁと思ってます。当然、こういった設定をソースから切り出して一括指定したいときには、ファイルや規約による指定の方が有効なんでしょうけど・・・
えっと、いつものように話がまとまりませんが（汗）・・・正直、EJB3（@Entity除く）とかはちょっとアノテーション設定多すぎではないかと最近感じているので、一般に広まるのであればもっと洗練して欲しいというか・・・せっかくあるツールなんだから何か新しい可能性を探してみたい、というか・・・せっかく興味を持ったので色々試してみたい（笑）・・・ってところでしょうか。