概要
使用方法
- Spring 3.0.1 (アノテーション構成)
- 現在の構成では、プロキシ作成者として CGLib を使用していますが、これは私の好みではありません
- トランザクションは、特別な設定なしで構成されたアノテーションです
- すべての構成は、注釈 (
@Service、@Transactional、@ManagedResource、@Injectなど)で行われます。
- Hibernate 3.5 (エンティティには javax.persistence のアノテーションが付けられます)
ガイドラインのハイライト
- アノテーションが付けられた、
@Repositoryまたは@Serviceインターフェイスが必要なすべての Bean - コンストラクタ DI (再構成が不要な場合)
- コンストラクターにはデフォルトの可視性があります (
Foo(Bar bar) {...})
- コンストラクターにはデフォルトの可視性があります (
- Bean フィールドはfinalです (再構成が不要な場合)
- デフォルトのコンストラクターがありません
- 実装は、最終修飾子 ( )を使用してデフォルトで表示されます
final class Foo
問題
- CGLib は最終クラスをプロキシできません
- CGLib にはデフォルト (空の) コンストラクターが必要です
- 一部のサービスは JMX 経由で公開する必要があります
- CGLib によってプロキシされない限り、MBean エクスポータが機能しない
- 一部
@Transactional@Serviceの は、ファサード トランザクションに複数のサービスを含める必要があるファサード サービスを介してアクセスされます (例: 2 つのアプリケーション コンポーネントに対するオブザーバー サービス)。 - 一部のインターフェースには複数の実装があります (現在は で区別されています
@Qualifier) 。 - 将来のガイドライン (または機能があると便利) - 各アプリケーション モジュールには
beanRefContext.xml、内部アプリケーション コンテキストを構成するためのファイルがあります。
XML 構成を使用していたときは、上記のすべてのガイドラインを適用できましたが、注釈に切り替えると、Spring が正しく動作していないように見えます。
私のグループの開発者は、アノテーション構成を好みます (新しいコードを配線して記述する方が簡単なようです) が、Spring アプリケーション コンテキスト エラーの処理を防ぐためにコードに導入されたあらゆる種類の「ハック」に気付きました。
質問）
- アノテーション構成を使用する際に従うべきベストプラクティスはありますか?
- インターフェースごとに複数の実装を使用する場合 (
@Primaryまたはの使用を減らしようとしている@Qualifier) - 使用時
@Transactional - 使用時
@ManagedResource - 上記を組み合わせて使用する場合
- インターフェースごとに複数の実装を使用する場合 (
- CGLib の使用を停止し、アノテーション構成を保持したまま、アノテーション付きの MBean をエクスポートできる方法はありますか?
- 私のガイドラインのほとんど (できればすべて) を維持するための適切な実装は何ですか?