春-構成上の混乱？

Springをどこかで読んだところ、設定よりも便利です。しかし、Springの人々は、構成に対して非常に多くの変更を取り入れているため、XML構成または注釈を使用することに本当に混乱しています。

XMLと注釈の使用について、誰でも確実な方法論または経験則を提案してほしい。

SOの例は、私のような多くの初心者が構成について混乱していることを示しています。

• リンク-1

  私は、機能の背後を把握していないようだ<context:annotation-config>と<context:component-scan>。

  私が読んだものから、それらは異なる注釈（@ Required、@ Autowiredなどと@ Component、@ Repository、@ Serviceなど）を処理しているようですが、私が読んだものからは、同じBeanポストプロセッサクラスを登録しています。

  さらに私を混乱させるために、annotation-config属性があります<context:component-scan>...

• リンク2

  私はまだコンポーネントスキャンタグを持っています：

  <context:component-scan base-package="com.mycompany.maventestwebapp" />

  しかし、私は別のタグ（同様のタスクを持っているように見える）も持っています。これは次のタグです。

  <annotation-driven />

  これら2つのタグの違いは何ですか？他の「奇妙な」ことは、前の例（注釈駆動型タグを使用しない）は、Spring MVCテンプレートプロジェクトを使用してSTSによって作成されたプロジェクトと非常に似ているが、注釈駆動型タグを構成から削除した場合です。ファイルは、プロジェクトが実行され、私に次のエラー与えることはありません：HTTPステータス404を- ...

Spring 3.2はプロキシ用にcglibを必要としなくなりましたが、下位バージョンはcglibを使用します。SpringSourceブログからの引用

そのようなプロキシを生成するために、Springはcglibと呼ばれるサードパーティのライブラリを使用します。残念ながら、このプロジェクトは現在アクティブではありません。Spring 3.2では、SpringがデフォルトでJavassistを使用する可能性が非常に高いです。

これらは、Springが構成上の混乱であることを示唆するのに十分ですか？

Springは、「構成よりも規約」があるフレームワークを提供することを目的としています。ただし、実際には、Springアプリケーションにはある程度の構成が必要です。

Spring 2.5.x以前のバージョンでは、一般的なイディオムはこの構成をXML経由で提供することでした。Spring 3.0以降の慣用的な方法は、アノテーション（Java EE6 / 7でも推奨されるもの）を使用することです。

余談ですが、注釈が付けられたJPAエンティティを見るのはおかしいかもしれません（追加？）。4つ以上の注釈を1つのフィールドに追加するのはかなり簡単です。

<annotation-driven />

これがどこから来るのかXMLスキーマを指定する必要があります。

トランザクションマネージャーを定義する際のJPAトランザクション処理戦略のコンテキストである可能性が最も高い（Springのドキュメントで9.5.6。@ Transactionalの使用を参照）

アノテーション駆動型トランザクション処理を定義すると、Spring AOPはメソッドのアスペクトを自動的に作成して、メソッドの呼び出し前にトランザクションを開始（または既存のチェック）し、メソッドの呼び出しが終了した後でコミット（例外の場合はロールバック）します。

シングルトンの実装がある場合に注釈ベースのIoC / Bean作成が便利ですが、それを交換する必要があるかもしれません。

異なる依存クラス/インスタンスでBeanを繰り返し再利用する必要がある状況とは対照的です。

これらの場合、私はBeanをconfigで宣言し、通常、必要な依存関係のコンストラクター注入を行います。次に、上記のBeanを使用するクラスで、私は@Autowireそれから@Qualifier("")-それがファクトリーが機能すると想定している方法です。

シングルトンは、1つの結果のみを返すファクトリメソッドです。これが簡単に当てはまらない場合は、混ぜる必要がある場合です。

コンポーネントスキャンを使用する場合と使用しない場合については、これは実際には上記の基準と適切な判断の対象となります。私は通常、パッケージコンポーネントのスキャンについて非常に明確です。そうすれば、IoCセットアップの残りの部分をテストしながら、外部の依存関係（dbなど）をモックアウトできるテスト用の別のアプリケーションコンテキストを作成できます。

また@Component、プロジェクトにはライブラリコードはありません。いつどのようにBeanを使用する必要があるかわからないので、もし@Componentそれを使用すると、誤ってスキャンでそれを拾ってしまい、再利用性が制限されてしまいます。これらの場合、私は通常、ライブラリに定義されたアプリケーションコンテキストをいくつかの便利なBean宣言でデフォルトに設定し、私のメインプロジェクトはそのアプリケーションコンテキストへのインポートに含めることができます。

ここには宗教はありません。伝えるだけの経験

Springはオプションを提供し、元々はxmlベースの配線のみでした。後で注釈ベースの配線が追加されました。
両方を組み合わせて使用​​できるようになりました（多くの人がそうしています）。
豊富なドキュメントがSpringに含まれており、SpringsourceのWebサイトからダウンロードできます。専門的なトレーニング（これを行ったことはなく、保証することもできません）と、かなりの数の優れた本（私はAPressのPro Springが好きで、使用しているSpringのバージョンに適したリリースを選択しています）があります。