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