XML 構成と注釈ベースの構成 [終了]

StackOverflow https://stackoverflow.com/questions/182393

  •  06-07-2019
  •  | 
  •  

質問

私が最近取り組んでいるいくつかの大規模プロジェクトでは、どちらか (XML または注釈) を選択することがますます重要になっているようです。プロジェクトが成長するにつれて、保守性のために一貫性が非常に重要になります。

私の質問は次のとおりです。注釈ベースの構成に対する XML ベースの構成の利点は何ですか?また、XML ベースの構成に対する注釈ベースの構成の利点は何ですか?

役に立ちましたか？

解決

注釈には用途がありますが、XML構成を殺すための特効薬ではありません。 2つを混ぜることをお勧めします！

たとえば、Springを使用している場合、アプリケーションの依存性注入部分にXMLを使用することは完全に直感的です。これにより、コードの依存関係が使用されるコードから離れますが、対照的に、依存関係を必要とするコードで何らかの注釈を使用すると、コードはこの自動構成を認識します。

ただし、トランザクション管理にXMLを使用する代わりに、アノテーションでメソッドをトランザクションとしてマークすることは完全に理にかなっています。これはプログラマーがおそらく知りたい情報だからです。ただし、インターフェイスは、SubtypeXではなくSubtypeYとしてインジェクトされることになります。これは、SubtypeXをインジェクトする場合、コードを変更する必要があるためです。 XMLを使用する場合、XMLマッピングを変更するだけで済み、変更は非常に迅速かつ簡単です。

JPAアノテーションを使用したことがないので、それらがどれほど優れているかわかりませんが、XMLでBeanのデータベースへのマッピングを残すことも良いと主張します。情報から来た、それはその情報で何ができるかだけ気にする必要があります。しかし、JPAが好きな場合（私はそれについて何の経験もありません）、ぜひともやってみてください。

一般的に： 注釈が機能を提供し、それ自体でコメントとして機能し、この注釈なしで正常に機能するためにコードを特定のプロセスに結び付けない場合は、注釈に進みます。たとえば、トランザクションとしてマークされたトランザクションメソッドは、その動作ロジックを強制終了することはなく、適切なコードレベルのコメントとしても機能します。それ以外の場合、この情報はおそらくXMLとして最も適切に表現されます。最終的にはコードの動作に影響しますが、コードの主な機能を変更せず、したがってソースファイルに属さないためです。

他のヒント

ここには、外部化されたメタデータとインライン化されたメタデータの問題があります。オブジェクトモデルが1つの方法でしか永続化されない場合、インラインメタデータ（つまり、アノテーション）はよりコンパクトで読みやすくなります。

ただし、各アプリケーションが異なる方法でモデルを永続化するようにオブジェクトモデルが異なるアプリケーションで再利用された場合、メタデータ（つまりXML記述子）の外部化がより適切になります。

どちらも優れていないため、アノテーションはよりファッショナブルですが、両方ともサポートされています。結果として、JPAのような新しいヘアオンファイアフレームワークは、それらをより重視する傾向があります。どちらも十分ではないことがわかっているため、ネイティブHibernateなどのより成熟したAPIは両方を提供します。

私は常にアノテーションをある種の指標として考えています。 何 クラスができること、または どうやって それは他者と対話します。

一方、Spring XML 構成は私にとっては単なるものです。 構成

たとえば、プロキシの IP とポートに関する情報は、明確に XML ファイルに入力され、それが実行時設定になります。

使用する @Autowire,@Element クラスをどう扱うかをフレームワークに示すには、アノテーションを上手に使用します。

URLを @Webservice 注釈のスタイルが悪い。

しかし、これは単なる私の意見です。インタラクションと構成の間の境界線は必ずしも明確ではありません。

Springを使用して数年になりますが、必要なXMLの量は間違いなく退屈です。 Spring 2.5の新しいXMLスキーマとアノテーションサポートの間では、通常、次のことを行います。

  1. ＆quot; component-scan＆quot;の使用@ Repository、@ Service、または@Componentを使用するクラスを自動ロードします。通常、すべてのBeanに名前を付け、@ Resourceを使用してそれらを結び付けます。この配管はあまり頻繁に変更されないため、注釈を付けるのが理にかなっています。

  2. 「aop」を使用するすべてのAOPの名前空間。これは本当にうまくいきます。 @Transactionalをあちこちに配置するのは一種のドラッグなので、私はまだトランザクションにも使用しています。任意のサービスまたはリポジトリのメソッドに名前付きポイントカットを作成して、非常に迅速にアドバイスを適用できます。

  3. Hibernateを設定するには、HibernateJpaVendorAdapterとともにLocalContainerEntityManagerFactoryBeanを使用します。これにより、Hibernateはクラスパス上の@Entityクラスを簡単に自動検出できます。次に、＆quot; factory-bean＆quot;を使用して名前付きSessionFactory Beanを作成します。および「工場メソッド」 LCEMFBを参照。

注釈のみのアプローチを使用する際の重要な部分は、「Bean名」の概念が多かれ少なかれなくなります（重要ではなくなります）。

＆quot; bean名＆quot; Springでは、実装クラスをさらに抽象化したレベルを作成します。 XMLでは、BeanはBean名に関連して定義および参照されます。アノテーションを使用すると、クラス/インターフェースによって参照されます。 （Bean名は存在しますが、知る必要はありません）

余分な抽象化を取り除くと、システムが簡素化され、生産性が向上すると強く信じています。 大規模プロジェクトの場合、XMLを削除することで得られるメリットは大きいと思います。

可視性は、XMLベースのアプローチの大きな利点だと思います。 XMLドキュメントをナビゲートするためのさまざまなツール（つまり、Visual Studio + ReSharperの[ファイル構造]ウィンドウ）を考えると、XMLはそれほど悪くないことがわかります。

確かに混合アプローチをとることはできますが、プロジェクトの新しい開発者がさまざまなオブジェクトが構成またはマッピングされている場所を把握することが難しくなる可能性があるため、それは私にとって危険なようです。

わかりません。結局、XML Hellはそれほど悪くないように思えます。

アノテーションで設定できないオプションがいくつかあるため、設定するものすべてに依存します。注釈の横から見た場合：

  • プラス：アノテーションはあまりしゃべれません
  • マイナス：注釈は見えにくくなります

より重要なのはあなた次第です...

一般的に、1つの方法を選択して、製品の一部の閉じた部分で使用することをお勧めします...

（いくつかの例外を除きます。たとえば、XMLベースの構成を選択した場合、@ Autowireアノテーションを使用しても構いません。混合しますが、これは読みやすさと保守性の両方に役立ちます）

リファクタリングや他のコード変更など、比較する他の側面があります。 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プロジェクトに取り組んでおり、通常は異なる開発サーバーとテストサーバーにデプロイします。だから私は分割しました：

  • サーバー固有の構成（サーバー上のリソースへの絶対パスと同様）：Spring XMLファイル
  • 他のBeanのメンバーとしてBeanを注入（または多くのBeanでSpring XML定義値を再利用）：注釈

主な違いは、すべてのサーバー固有の構成を変更するためにコードを再コンパイルする必要はなく、xmlファイルを編集するだけです。 また、関係するすべてのコードを理解していないチームメンバーが一部の構成を変更できるという利点もあります。

DIコンテナの範囲では、アノテーションベースのDIはJavaアノテーションの使用を乱用していると考えています。と言って、プロジェクトで広く使用することはお勧めしません。あなたのプロジェクトが本当にDIコンテナのパワーを必要とするなら、Xmlベースの設定オプションでSpring IoCを使用することをお勧めします。

単体テストのためだけの場合、開発者はコーディングにDependency Injectパターンを適用し、EasyMockやJMockなどのモックツールを利用して依存関係を回避する必要があります。

間違ったコンテキストでDIコンテナを使用しないようにしてください。

常に特定のJavaコンポーネント（クラス、メソッド、またはフィールド）にリンクされる構成情報は、注釈で表すのに適した候補です。この場合、構成がコードの目的の中核である場合、注釈は特にうまく機能します。注釈には制限があるため、各コンポーネントが1つの構成しか持てない場合にも最適です。複数の構成、特にアノテーションを含むJavaクラスの外部にあるものを条件とする構成に対処する必要がある場合、アノテーションは解決するよりも多くの問題を引き起こす可能性があります。最後に、注釈はJavaソースコードを再コンパイルしないと変更できないため、実行時に再構成が必要なものは注釈を使用できません。

次のリンクを参照してください。役に立つかもしれません。

  1. アノテーションvs XML、長所と短所
  2. http://www.ibm.com/developerworks/library/j- cwt08025 /

これは、古典的な「構成とコンベンション」の質問です。ほとんどの場合、個人の好みによって答えが決まります。ただし、個人的には、コンベンションよりも構成（つまり、XMLベース）を好みます。 IMO IDEは、XMLベースのアプローチの構築と維持にしばしば関係するXML地獄のいくつかを克服するのに十分なほど堅牢です。最終的には、構成の利点（XML構成ファイルを構築、保守、および展開するユーティリティを構築するなど）が、長期的にはコンベンションよりも優れていることに気付きます。

両方を使用します。ほとんどがXMLですが、共通のクラスから継承し、共通のプロパティを持つBeanの束がある場合、スーパークラスでそれらのアノテーションを使用するため、各Beanに同じプロパティを設定する必要はありません。私は少しコントロールがおかしいので、単に自動配線するのではなく@Resource（name =＆quot; referredBean＆quot;）を使用します（元のreferedBeanと同じクラスの別のBeanが必要になった場合、多くの手間を省きます） ）。

私の経験から、アノテーション設定の長所と短所があります：

  • 一度だけ行われ、通常は頻繁に変更されないため、JPAの設定に関しては、アノテーションの設定に固執することを好みます。構成の全体像を見る可能性に関して懸念があるかもしれません-この場合、MSQLWorkbenchダイアグラムを使用します。
  • Xml構成は、アプリケーションの全体像を把握するのに非常に適していますが、実行時までエラーを見つけるのは面倒かもしれません。この場合、Springの @Configuration アノテーションは、より大きな画像を見ることができ、コンパイル時に構成を検証することもできるため、より良い選択として聞こえます。
  • Springの設定に関しては、両方のアプローチを組み合わせることを好みます。 @Configuration アノテーションを、dataSourceおよびcontext：component-scan base-package =＆quotのようなSpringの設定用のサービスおよびクエリインターフェイスとxml構成で使用します; ...＆quot;
  • ただし、ビジネスプロセス全体の全体像を把握することは非常に重要であるため、xml構成では、フロー構成（Spring Web FlowまたはLexaden Web Flow）に関してJavaアノテーションを使用します。また、アノテーションアプローチで実装するのは面倒です。

私は両方のアプローチを組み合わせることを好みます-構成の地獄を最小限にするJavaアノテーションと必須のXML最小値

Spring Frameworkの場合、@ Componentアノテーションを使用して＆quot; component-scan＆quot;を設定できるというアイデアが好きです。これにより、SpringがJava Beanを検出できるため、すべてのBeanをXMLやJavaConfigで定義する必要がなくなります。たとえば、単純に他のクラスに（理想的にはインターフェースを介して）接続する必要があるステートレスシングルトンJava Beanの場合、このアプローチは非常にうまく機能します。一般に、Spring Beanの場合、Beanを定義するためにSpring XML DSLからほとんどの部分を移動しましたが、JavaConfigとSpring Annotationsを使用することをお勧めします。 Spring XML構成を取得します。 JavaConfig / AnnotationsがXML構成を使用して利用できることを実行できないことがわかった特定のまれなケースで、2つを混在させています。

Hibernate ORM（JPAをまだ使用していません）の場合、ドメインモデルクラスのアノテーションがある程度クリーンアーキテクチャは、過去数年にわたって採用してきた階層化アーキテクチャスタイルです。違反が発生するのは、コア層がHibernateやJPAライブラリなどの永続性関連のものに依存する必要があり、ドメインモデルPOJOの永続性が無視されにくくなるためです。実際、コアレイヤーは他のインフラストラクチャにまったく依存しないことになっています。

ただし、クリーンアーキテクチャが「お茶」ではない場合は、個別のXMLマッピングファイルよりもドメインモデルクラスでHibernate / JPA注釈を使用することの利点（利便性や保守性など）が確実にあることがわかります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top