XML構成と注釈ベースの構成
最近取り組んでいるいくつかの大きなプロジェクトでは、どちらかを選択することがますます重要になっているようです（XMLまたはアノテーション）。プロジェクトが成長するにつれて、保守性にとって一貫性が非常に重要になります。
私の質問は、注釈ベースの構成に対するXMLベースの構成の利点と、XMLベースの構成に対する注釈ベースの構成の利点は何ですか？
注釈には用途がありますが、XML構成を殺すための特効薬ではありません。 2つを混ぜることをお勧めします！
たとえば、Springを使用している場合、アプリケーションの依存性注入部分にXMLを使用することは完全に直感的です。これにより、コードの依存関係が使用されるコードから離れますが、対照的に、依存関係を必要とするコードで何らかの注釈を使用すると、コードはこの自動構成を認識します。
ただし、トランザクション管理にXMLを使用する代わりに、アノテーションでメソッドをトランザクションとしてマークすることは完全に理にかなっています。これはプログラマがおそらく知りたい情報だからです。ただし、インターフェイスは、SubtypeXではなくSubtypeYとしてインジェクトされることになります。これは、SubtypeXをインジェクトする場合、コードを変更する必要があるためです。 XMLを使用する場合、XMLマッピングを変更するだけで済み、変更はかなり迅速で簡単です。
私はJPAアノテーションを使用したことがないので、それらがどれほど良いかはわかりませんが、XMLでBeanのデータベースへのマッピングを残すことも良いと主張します。 、情報で何ができるかを気にするだけです。しかし、JPAが好きな場合（私はそれについて何の経験もありません）、ぜひともやってください。
一般に、注釈が機能を提供し、それ自体でコメントとして機能し、この注釈なしで正常に機能するためにコードを特定のプロセスに結び付けない場合、注釈に進みます。たとえば、トランザクションとしてマークされたトランザクションメソッドは、その操作ロジックを強制終了することはなく、適切なコードレベルのコメントとしても機能します。それ以外の場合、この情報はおそらくXMLとして最も適切に表現されます。最終的にはコードの動作に影響しますが、コードの主な機能を変更せず、したがってソースファイルに属しません。
ここには、外部化されたメタデータとインライン化されたメタデータの問題があります。オブジェクトモデルが1つの方法でのみ永続化される場合、インラインメタデータ（つまり、注釈）はよりコンパクトで読みやすくなります。
ただし、各アプリケーションが異なる方法でモデルを永続化するようにオブジェクトモデルが異なるアプリケーションで再利用された場合、メタデータ（つまりXML記述子）の外部化がより適切になります。
どちらも優れていないため、両方がサポートされていますが、アノテーションはよりファッショナブルです。その結果、JPAのような新しいFire-on-Fireフレームワークは、それらをより重視する傾向があります。どちらも十分ではないことがわかっているため、ネイティブHibernateのようなより成熟したAPIは両方を提供します。
私はいつも、注釈をwhatクラスができるか、またはhowが他のクラスと対話することを示す何らかの指標として考えています。
私にとってSpring XMLの構成は、それだけですconfiguration
たとえば、プロキシのIPおよびポートに関する情報は、明確にXMLファイルに入力されます。これはランタイム構成です。
@Autowire、@Elementを使用して、フレームワークがクラスをどう処理するかを、アノテーションを適切に使用することを示します。
URLを@Webservice注釈に入れるのはスタイルが悪いです。
しかし、これは私の意見です。相互作用と構成の境界は必ずしも明確ではありません。
私はここ数年Springを使用していますが、必要なXMLの量は間違いなく退屈です。 Spring 2.5の新しいXMLスキーマと注釈サポートの間では、通常、次のことを行います。
「コンポーネントスキャン」を使用して、@ Repository、@ Service、または@Componentを使用するクラスを自動ロードします。通常、すべてのBeanに名前を付け、@ Resourceを使用してそれらを結び付けます。この配管はあまり頻繁には変わらないので、注釈を付けるのが理にかなっています。
すべてのAOPに「aop」名前空間を使用します。これは本当にうまくいきます。 @Transactionalをあちこちに配置することはドラッグのようなものなので、私は今でもトランザクションに使用しています。任意のサービスまたはリポジトリのメソッドに名前付きポイントカットを作成し、非常に迅速にアドバイスを適用できます。
LocalContainerEntityManagerFactoryBeanをHibernateJpaVendorAdapterとともに使用して、Hibernateを構成します。これにより、Hibernateはクラスパス上の@Entityクラスを簡単に自動検出できます。次に、LCEMFBを参照する「factory-bean」と「factory-method」を使用して、名前付きSessionFactory Beanを作成します。
XMLベースのアプローチでは、可視性が大きなメリットになると思います。 XMLドキュメントをナビゲートするためのさまざまなツール（つまり、Visual Studio + ReSharperの[ファイル構造]ウィンドウ）を考えると、XMLはそれほど悪くないことがわかります。
確かに混合アプローチを取ることができますが、プロジェクトの新しい開発者がさまざまなオブジェクトが構成またはマッピングされている場所を把握することが困難になる可能性があるため、それは私にとって危険なようです。
知りません;結局、XML Hellはそれほど悪くないように思えます。
注釈のみのアプローチを使用する際の重要な部分は、「Bean名」の概念が多かれ少なかれなくなることです（重要ではなくなります）。
Springの「Bean名」は、実装クラスをさらに抽象化したレベルを形成します。 XMLでは、BeanはBean名に関連して定義および参照されます。アノテーションを使用すると、クラス/インターフェースによって参照されます。 （Bean名は存在しますが、知る必要はありません）
不要な抽象化を取り除くことでシステムが簡素化され、生産性が向上すると強く信じています。 largeプロジェクトの場合、XMLを削除することで得られるメリットは大きいと思います。
リファクタリングや他のコード変更など、比較する他の側面があります。 XMLを使用する場合、すべてのXMLコンテンツを処理する必要があるため、リファクタリングを行うのに多大な労力が必要です。ただし、注釈を使用する場合は簡単です。
私の好ましい方法は、Javaアノテーションなしの（または最小限の）ベースの構成です。 http://static.springsource.org/spring/docs/3.0.x/spring-framework- reference/html/beans.html＃beans-Java
アノテーションでは設定できないオプションがいくつかあるため、設定するものすべてに依存します。注釈の側面から見ると：
- プラス：アノテーションはあまりしゃべれない
- マイナス：注釈はあまり見えません
より重要なのはあなた次第です...
一般に、1つの方法を選択し、製品の一部の閉じた部分で使用することをお勧めします...
（いくつかの例外を除きます：たとえば、XMLベースの構成を選択する場合、@ Autowireアノテーションを使用しても構いません。混合しますが、これは読みやすさと保守性の両方に役立ちます）
ミックスも最高だと思いますが、構成パラメータのタイプにも依存します。私はまたSpringを使用するSeamプロジェクトに取り組んでおり、通常は異なる開発およびテストサーバーにデプロイします。だから私は分割しました：
- サーバー固有の構成（サーバー上のリソースへの絶対パスのような）：Spring XMLファイル
- 他のBeanのメンバーとしてBeanを注入（または多くのBeanでSpring XML定義値を再利用）：注釈
主な違いは、変更するサーバー固有の構成すべてに対してコードを再コンパイルする必要はなく、xmlファイルを編集するだけです。また、関係するすべてのコードを理解していないチームメンバーが一部の構成を変更できるという利点もあります。
私は間違っているかもしれませんが、注釈は（Javaの@TagやC＃の[属性]のように）コンパイル時のオプションであり、XMLは実行時のオプションだと思っていました。私にとってそれは同等ではなく、長所と短所が異なると言います。
DIコンテナーの範囲では、注釈ベースのDIはJava注釈の使用を乱用しています。それを言って、プロジェクトで広く使用することはお勧めしません。本当にDIコンテナーのパワーが必要なため、Xmlベースの構成オプションでSpring IoCを使用することをお勧めします。
単体テストのためだけであれば、開発者はコーディングにDependency Injectパターンを適用し、EasyMockやJMockなどのモックツールを利用して依存関係を回避する必要があります。
間違ったコンテキストでDIコンテナを使用しないようにしてください。
常に特定のJavaコンポーネント（クラス、メソッド、またはフィールド）にリンクされる構成情報は、注釈で表すのに適した候補です。この場合、注釈が特にうまく機能するのは、構成がコードの目的の中核である場合です。注釈には制限があるため、各コンポーネントが1つの構成しか持てない場合にも最適です。複数の構成、特に注釈を含むJavaクラス以外の条件に基づいた構成に対処する必要がある場合、注釈は解決するよりも多くの問題を引き起こす可能性があります。最後に、注釈はJavaソースコードを再コンパイルしないと変更できないため、実行時に再構成が必要なものは注釈を使用できません。
以下のリンクを参照してください。彼らも役に立つかもしれません。
私は両方を使用します。ほとんどがXMLですが、共通クラスから継承し、共通のプロパティを持つBeanの束がある場合、スーパークラスでそれらのアノテーションを使用するため、各Beanに同じプロパティを設定する必要はありません。私はちょっとしたコントロールが好きなので、単に自動配線するのではなく@Resource（name = "referredBean"）を使用します（元のreferedBeanと同じクラスの別のBeanが必要になった場合、多くの手間を省きます） 。
私の経験から、注釈構成の長所と短所がいくつかあります。
- JPAの構成に関しては、一度行われ、通常はあまり頻繁に変更されないため、アノテーション構成に固執することを好みます。構成の全体像を見る可能性に関して懸念があるかもしれません-この場合、MSQLWorkbenchダイアグラムを使用します。
- Xml構成は、アプリケーションの全体像を把握するのに非常に適していますが、実行時までエラーを見つけるのは面倒かもしれません。この場合、Spring @ Configurationアノテーションは、より大きな画像を見ることができ、コンパイル時に構成を検証することもできるため、より良い選択として聞こえます。
- Springの構成に関しては、両方のアプローチを組み合わせることを好みます：@ Configurationアノテーションをサービスおよびクエリインターフェイスで使用し、dataSourceのxml構成とcontext：component-scan base-package = "... 」
- しかし、XML構成ビットJavaアノテーションは、フロー構成（Spring Web FlowまたはLexaden Web Flow）に関しては、ビジネスプロセス全体の全体像を確認することが非常に重要であるため、注釈です。アノテーションアプローチで実装します。
私は両方のアプローチを組み合わせることを好みます-Javaアノテーションと、構成の地獄を最小限にする重要なxmlの最小値。
Spring Frameworkの場合、@ Componentアノテーションを使用し、「component-scan」オプションを設定して、SpringがJava Beanを見つけることができるように定義する必要がないたとえば、ステートレスシングルトンJava他のクラスに（理想的にはインターフェイスを介して）接続する必要があるBean）の場合、このアプローチは非常にうまく機能します。一般的に、Spring Beanでは、Beanの定義に関してSpring XML DSLからほとんどの部分を移動しましたが、JavaConfigとSpring Annotationsを使用することをお勧めします。 SpringのXML構成を取得します.JavaConfig/AnnotationsがXML構成を使用して利用できることを実行できないことがわかった特定のまれなケースで、2つを混在させます。
Hibernate ORM（JPAをまだ使用していません）の場合、ドメインモデルクラスのアノテーションがある程度違反するため、XMLマッピングファイルの方が好きです The Clean Architecture これは過去に採用した階層化アーキテクチャスタイルです数年。違反が発生するのは、コア層がHibernateやJPAライブラリなどの永続性関連のものに依存する必要があり、ドメインモデルPOJOの永続性が少し無視されるためです。実際、コアレイヤーは他のインフラストラクチャにまったく依存しないことになっています。
ただし、The Clean Architectureが「一杯」ではない場合、個別のXMLマッピングファイルよりもドメインモデルクラスでHibernate/JPAアノテーションを使用することの利点（利便性や保守性など）が確実にあることがわかります。
これは古典的な「構成対コンベンション」の質問です。ほとんどの場合、個人の好みによって答えが決まります。ただし、個人的には、コンベンションよりも構成（つまり、XMLベース）を好みます。 IMO IDEは、XMLベースのアプローチの構築と維持にしばしば関連するXML地獄のいくつかを克服するのに十分なほど堅牢です。最終的には、構成の利点（XML構成ファイルを構築、保守、および展開するユーティリティを構築するなど）が、長期的にはコンベンションよりも優れていることに気付きます。