Spring 3 アノテーションを使用する際のベスト プラクティスを探しています。
私は現在、Spring 3 に移行していますが、これまでに読んだことから、注釈の使用と XML 構成からの移行に重点が置かれていることがわかります。
実際に推奨されるのは、両方のスタイルを組み合わせることです。注釈は、頻繁に変更されないもの、または実行ごとに変更されるもの (たとえば@Controller、アプリケーションの存続期間中はそのままです) をカバーします。 XML に設定可能である必要があります (たとえば、メール SMTP アドレス、アプリケーションが通信する Web サービスのエンドポイントなど)。
私の質問は、注釈に何をどの程度入れるべきかということです。
注釈が物事を容易にする代わりに困難にするのはどの時点ですか? テクノロジー (Spring 3) は、そのようなステートメントを作成できるように完全に採用されていますか?それとも、人々がそれを使用して経験を積み、問題について考えるのにもう少し時間がかかりますか?
真の高度な情報を入手することは常に困難です。
「私のブログを見てください。Spring Source の Web サイトから hello ワードのチュートリアルをコピーしました...どこにでもファンシーな注釈を付けることができるようになりました。これは、がんや飢餓を含むすべての問題の解決策です。」は本当に役に立ちません。
右側のスプリング コアにはいくつかの目的がありましたが、その中には次のようなものがあります。
これらすべてのニーズに対する注釈の失敗:
実際、私たちは焦点を移しました:
したがって、意味がある場合は注釈を使用します。定型コードを純粋に削除する場合は、冗長性。単体テストでサービスのスタブ実装を提供するだけであっても、構成可能にしたいもののために XML 構成ファイルを使用するようにします。
Kunalが指摘した@Valueように、外部プロパティファイルで構成されたプロパティに使用します。PropertyPlaceholderConfigurer
いつ xml を使用するかについての厳密な規則はありませんが、私は xml を使用します。
あなたのコメントに応えて: 春は非常に広く採用されていますが、「良い」と「悪い」は非常に主観的です。私のセリフでさえ、普遍的な真実ではありません。XML、注釈、およびプログラムによる構成はすべて目的のために存在し、各開発者/企業には好みがあります。
私が言ったように、厳密な境界線はなく、注釈に関する普遍的な良い習慣もありません。
アノテーションの使用によって問題が発生する可能性がある 2 つのケースがあると思います。まず、エンティティに複雑な名前付きクエリ (JPA) を記述したい場合。いくつかのエンティティー・コードのサンプルを見て、そのコードが本当に Java コードであるかどうかを自問しました。プログラム コードに多くのメタデータがあると、コードの可読性が低下し、クリーン コードの原則が失われます。
2 番目の問題は、JVM バージョン間の移植性です。注釈は機能 1.5 以降です。ソフトウェアが以前の JVM バージョンをサポートする必要がある場合は、これらを使用しないでください。
とにかく、いつでも疑いなく注釈を楽しむことができ、プロパティがまだそこにあるかどうか、または正しく入力されているかどうかなどを確認するために IDE タブを変更せずに時間を割くことができます。
非常に小さなプロジェクトの場合、春に宣言するものが多すぎない場合は、XML バージョンを使用できます。しかし、巨大なプロジェクトに参加している場合、10 個の xml 構成があると非常に面倒になる可能性があります。
これはおそらくあまり役に立たないでしょうが、クラスパススキャンが必要なため、職場では自動配線を使用したくありません（ただし、パッケージで定義できると思います）。そのため、プロジェクトのサイズに応じてアプリケーションの起動時間が長くなります。