it-swarm.com.de

XML-Konfiguration versus annotationsbasierte Konfiguration

In einigen großen Projekten, an denen ich in letzter Zeit gearbeitet habe, scheint es immer wichtiger zu werden, das eine oder andere auszuwählen (XML oder Annotation). Während die Projekte wachsen, ist die Konsistenz für die Wartbarkeit sehr wichtig.

Meine Fragen sind: Was sind die Vorteile einer XML-basierten Konfiguration gegenüber einer Annotation-basierten Konfiguration und was sind die Vorteile einer Annotation-basierten Konfiguration gegenüber einer XML-basierten Konfiguration?

130
abarax

Anmerkungen haben ihre Verwendung, aber sie sind nicht die einzige Silberkugel, um die XML-Konfiguration zu beenden. Ich empfehle die beiden zu mischen!

Wenn Sie beispielsweise Spring verwenden, ist es völlig intuitiv, XML für den Abhängigkeitsinjektionsteil Ihrer Anwendung zu verwenden. Dadurch werden die Abhängigkeiten des Codes von dem Code, der ihn verwendet, entfernt. Im Gegensatz dazu macht die Verwendung einer Art Annotation im Code, der die Abhängigkeiten benötigt, den Code auf diese automatische Konfiguration aufmerksam.

Anstatt XML für die Transaktionsverwaltung zu verwenden, ist es jedoch durchaus sinnvoll, eine Methode mit einer Anmerkung als transaktiv zu kennzeichnen, da dies Informationen sind, die ein Programmierer wahrscheinlich wissen möchte. Aber dass ein Interface als SubtypY anstatt als SubtypEX injiziert wird, sollte nicht in die Klasse aufgenommen werden, denn wenn Sie jetzt SubtypEX injizieren möchten, müssen Sie Ihren Code ändern, während Sie zuvor sowieso einen Schnittstellenvertrag hatten Mit XML müssten Sie lediglich die XML-Zuordnungen ändern. Dies ist relativ schnell und problemlos möglich.

Ich habe keine JPA-Annotationen verwendet, daher weiß ich nicht, wie gut sie sind, aber ich würde argumentieren, dass es auch gut ist, die Zuordnung von Beans zur Datenbank in XML zu belassen, da es dem Objekt egal sein sollte, woher seine Informationen stammen sollte es nur egal sein, was es mit seinen Informationen anfangen kann. Aber wenn Sie JPA mögen (ich habe keine Erfahrung damit), machen Sie es auf jeden Fall.

Im Allgemeinen gilt: Wenn eine Anmerkung Funktionen bereitstellt und selbst als Kommentar fungiert und den Code nicht an einen bestimmten Prozess gebunden hat, um ohne diese Anmerkung normal zu funktionieren, sollten Sie Anmerkungen vornehmen. Eine Transaktionsmethode, die als Transaktionsmethode gekennzeichnet ist, bricht nicht ihre Betriebslogik ab und dient auch als guter Kommentar auf Codeebene. Andernfalls werden diese Informationen wahrscheinlich am besten als XML ausgedrückt, da sie zwar letztendlich die Funktionsweise des Codes beeinflussen, die Hauptfunktionalität des Codes jedoch nicht ändern und daher nicht in die Quelldateien gehören.

197
MetroidFan2002

Es gibt hier ein größeres Problem, das von ausgelagerten vs inline Metadaten. Wenn Ihr Objektmodell immer nur auf eine Weise erhalten bleibt, sind eingebettete Metadaten (d. H. Anmerkungen) kompakter und lesbarer.

Wenn Ihr Objektmodell jedoch in verschiedenen Anwendungen so wiederverwendet wurde, dass jede Anwendung das Modell auf unterschiedliche Weise beibehalten wollte, wird die Externalisierung der Metadaten (d. H. XML-Deskriptoren) angemessener.

Keiner ist besser, und so werden beide unterstützt, obwohl Anmerkungen modischer sind. Infolgedessen legen neue Hair-on-Fire-Frameworks wie JPA tendenziell mehr Gewicht auf sie. Ausgereiftere APIs wie native Hibernate bieten beides, da bekannt ist, dass keines von beiden ausreicht.

30
skaffman

Ich denke immer an Annotationen als eine Art Indikator für was, zu dem eine Klasse fähig ist, oder wie, der mit anderen interagiert.

Spring XML-Konfiguration dagegen ist für mich genau das, Konfiguration

Informationen über die IP-Adresse und den Port eines Proxys werden beispielsweise definitiv in eine XML-Datei geschrieben, es handelt sich um die Laufzeitkonfiguration.

Mit @Autowire, @Element um das Framework anzugeben, was mit der Klasse zu tun ist, werden Anmerkungen verwendet.

Setzen Sie die URL in das @Webservice Anmerkung ist schlechter Stil.

Aber das ist nur meine Meinung. Die Grenze zwischen Interaktion und Konfiguration ist nicht immer klar.

13
Huibert Gill

Ich benutze Spring seit ein paar Jahren und die Menge an XML, die benötigt wurde, wurde definitiv mühsam. Zwischen den neuen XML-Schemas und der Annotation-Unterstützung in Spring 2.5 mache ich normalerweise folgende Dinge:

  1. Verwenden von "component-scan" zum automatischen Laden von Klassen, die @Repository, @Service oder @Component verwenden. Normalerweise gebe ich jeder Bohne einen Namen und verbinde sie dann mit @Resource. Ich finde, dass sich diese Installation nicht sehr oft ändert, daher sind Anmerkungen sinnvoll.

  2. Verwendung des Namensraums "aop" für alle AOP. Das funktioniert wirklich super. Ich benutze es immer noch auch für Transaktionen, da es ein Problem ist, @Transactional überall zu platzieren. Sie können benannte Pointcuts für Methoden in jedem Service oder Repository erstellen und die Ratschläge sehr schnell anwenden.

  3. Ich verwende LocalContainerEntityManagerFactoryBean zusammen mit HibernateJpaVendorAdapter, um Hibernate zu konfigurieren. Auf diese Weise kann Hibernate @Entity-Klassen im Klassenpfad auf einfache Weise automatisch erkennen. Dann erstelle ich eine benannte SessionFactory-Bean unter Verwendung von "factory-bean" und "factory-method" unter Bezugnahme auf den LCEMFB.

6
cliff.meyers

Ich denke, dass die Sichtbarkeit mit einem XML-basierten Ansatz ein großer Gewinn ist. Ich finde, dass das XML nicht wirklich so schlecht ist, da es verschiedene Tools zum Navigieren in XML-Dokumenten gibt (d. H. Das Dateistrukturfenster von Visual Studio + ReSharper).

Sie können sicherlich einen gemischten Ansatz wählen, aber das erscheint mir gefährlich, wenn auch nur deshalb, weil es möglicherweise für neue Entwickler in einem Projekt schwierig ist, herauszufinden, wo verschiedene Objekte konfiguriert oder zugeordnet sind.

Ich weiß es nicht; Am Ende scheint mir die XML-Hölle gar nicht so schlecht zu sein.

5
Charles Chen

Ein wichtiger Teil bei der Verwendung eines Annotation-Only-Ansatzes ist, dass das Konzept eines "Bean-Namens" mehr oder weniger verschwindet (bedeutungslos wird).

Die "Bean-Namen" in Spring bilden eine zusätzliche Abstraktionsebene über die implementierenden Klassen. Mit XML werden Beans definiert und relativ zu ihrem Bean-Namen referenziert. Mit Anmerkungen werden sie von ihrer Klasse/Schnittstelle referenziert. (Obwohl der Bean-Name existiert, müssen Sie ihn nicht kennen.)

Ich bin der festen Überzeugung, dass die Beseitigung überflüssiger Abstraktionen die Systeme vereinfacht und die Produktivität steigert. Für große Projekte denke ich, dass der Gewinn durch das Entfernen von XML beträchtlich sein kann.

5
krosenvold

Es gibt andere Aspekte zu vergleichen, wie Refactoring und andere Codeänderungen. Wenn Sie XML verwenden, ist das Refactoring sehr aufwändig, da Sie sich um den gesamten XML-Inhalt kümmern müssen. Bei der Verwendung von Anmerkungen ist dies jedoch einfach.

Mein bevorzugter Weg ist die Java basierte Konfiguration ohne (oder mit minimalen) Anmerkungen. http://static.springsource.org/spring/docs/3.0.x/spring-framework- Referenz/html/beans.html # beans-Java

4
takacsot

Es hängt davon ab, was alles Sie konfigurieren möchten, da es einige Optionen gibt, die nicht mit Anmerkungen konfiguriert werden können. Wenn wir es von der Seite der Anmerkungen sehen:

  • plus: Anmerkungen sind weniger gesprächig
  • minus: Anmerkungen sind weniger sichtbar

Es liegt an Ihnen, was wichtiger ist ...

Im Allgemeinen würde ich empfehlen, einen Weg zu wählen und alles über einen geschlossenen Teil des Produkts zu verwenden ...

(Mit einigen Ausnahmen: Wenn Sie z. B. XML-basierte Konfigurationen auswählen, ist die Verwendung der @Autowire-Annotation in Ordnung. Sie ist mischbar, trägt jedoch zur Lesbarkeit und Wartbarkeit bei.)

4
Juraj

Ich denke auch, dass eine Mischung die beste Sache ist, aber es hängt auch von der Art der Konfigurationsparameter ab. Ich arbeite an einem Seam-Projekt, das auch Spring verwendet, und setze es normalerweise auf verschiedenen Entwicklungs- und Testservern ein. Also habe ich aufgeteilt:

  • Serverspezifische Konfiguration (wie absolute Pfade zu Ressourcen auf dem Server): Spring-XML-Datei
  • Injizieren von Beans als Mitglieder anderer Beans (oder Wiederverwenden eines definierten Spring-XML-Werts in vielen Beans): Anmerkungen

Der Hauptunterschied besteht darin, dass Sie den Code nicht für alle sich ändernden serverspezifischen Konfigurationen neu kompilieren müssen. Bearbeiten Sie einfach die XML-Datei. Es gibt auch den Vorteil, dass einige Konfigurationsänderungen von Teammitgliedern vorgenommen werden können, die nicht den gesamten Code verstehen.

3
Cristian Vat

Ich könnte mich irren, aber ich dachte, Annotationen (wie in Javas @ Tag und C # 's [Attribut]) wären eine Option zur Kompilierung und XML eine Option zur Laufzeit. Das sagt mir die sind nicht gleich und haben unterschiedliche Vor- und Nachteile.

3
ARKBAN

Im Bereich des DI-Containers halte ich annotationsbasiertes DI für den Missbrauch der Verwendung von Java Annotation. Ich empfehle daher, es nicht in großem Umfang in Ihrem Projekt zu verwenden. Wenn dies in Ihrem Projekt der Fall ist Benötigt man wirklich die Leistung eines DI-Containers, würde ich empfehlen, Spring IoC mit einer XML-basierten Konfigurationsoption zu verwenden.

Wenn es nur um Unit-Tests geht, sollten Entwickler das Dependency Inject-Muster in ihrer Codierung anwenden und die Vorteile von Spott-Tools wie EasyMock oder JMock nutzen, um Abhängigkeiten zu umgehen.

Sie sollten versuchen, DI-Container nicht im falschen Kontext zu verwenden.

2
Thang

Konfigurationsinformationen, die immer mit einer bestimmten Java Komponente (Klasse, Methode oder Feld) verknüpft werden, sind ein guter Kandidat, um durch Anmerkungen dargestellt zu werden. Anmerkungen eignen sich in diesem Fall besonders gut, wenn die Konfiguration für den Zweck des Codes von zentraler Bedeutung ist. Aufgrund der Einschränkungen bei Anmerkungen ist es auch am besten, wenn jede Komponente immer nur eine Konfiguration haben kann. Wenn Sie sich mit mehreren Konfigurationen befassen müssen, insbesondere mit Konfigurationen, die von Bedingungen außerhalb der Klasse Java abhängig sind, die eine Anmerkung enthalten, können Anmerkungen mehr Probleme verursachen, als sie lösen. Schließlich können Annotationen nicht geändert werden, ohne den Quellcode Java neu zu kompilieren, sodass für alle Elemente, die zur Laufzeit neu konfiguriert werden müssen, keine Annotationen verwendet werden können.

Bitte beachten Sie folgende Links. Sie könnten auch nützlich sein.

  1. Anmerkungen vs. XML, Vor- und Nachteile
  2. http://www.ibm.com/developerworks/library/j-cwt08025/
2
tharindu_DG

Ich benutze beides. Meistens XML, aber wenn ich eine Reihe von Beans habe, die von einer gemeinsamen Klasse erben und gemeinsame Eigenschaften haben, verwende ich Annotationen für diese in der Superklasse, damit ich nicht für jedes Bean die gleichen Eigenschaften festlegen muss. Da ich ein bisschen ein Kontrollfreak bin, verwende ich @Resource (name = "referedBean") anstatt nur automatisch zu verdrahten (und erspare mir viel Ärger, wenn ich jemals eine andere Bean derselben Klasse wie die ursprüngliche referedBean benötige) .

1
Chochos

Nach meiner Erfahrung gibt es einige Vor- und Nachteile der Anmerkungskonfiguration:

  • Wenn es um die JPA-Konfiguration geht, da diese einmal durchgeführt wird und normalerweise nicht oft geändert wird, halte ich mich lieber an die Annotation-Konfiguration. Es gibt möglicherweise Bedenken hinsichtlich der Möglichkeit, ein größeres Bild der Konfiguration zu sehen - in diesem Fall verwende ich MSQLWorkbench-Diagramme.
  • Die XML-Konfiguration ist sehr gut, um ein größeres Bild der Anwendung zu erhalten, aber es kann schwierig sein, einige Fehler bis zur Laufzeit zu finden. In diesem Fall ist Spring @ Configuration Annotation die bessere Wahl, da Sie damit auch ein größeres Bild sehen und die Konfiguration beim Kompilieren überprüfen können.
  • In Bezug auf die Spring-Konfiguration kombiniere ich lieber beide Ansätze: benutze @ Konfiguration Annotation mit Services- und Query-Interfaces und die XML-Konfiguration für DataSource- und Spring-Konfigurationsmaterial wie den Kontext: component-scan base-package = "... "
  • Aber XML-Konfigurationsbits Java Anmerkungen, wenn es um die Flow-Konfiguration geht (Spring Web Flow oder Lexaden Web Flow), da es äußerst wichtig ist, ein größeres Bild des gesamten Geschäftsprozesses zu erhalten. Und das klingt umständlich mit Annotations Ansatz implementiert zu haben.

Ich bevorzuge es, beide Ansätze zu kombinieren - Java Annotationen und wesentliches XML-Minimum, das die Konfigurationshölle minimiert.

1

Für Spring Framework gefällt mir die Idee, die Annotation @Component zu verwenden und die Option "component-scan" festzulegen, damit Spring meine Java Beans findet, damit ich sie nicht definieren muss Alle meine Beans in XML, noch in JavaConfig. Zum Beispiel für statuslose Singleton Java Beans, die einfach mit anderen Klassen verbunden werden müssen (im Idealfall über eine Schnittstelle), funktioniert dieser Ansatz sehr gut. Im Allgemeinen habe ich mich für Spring Beans zum Definieren von Beans größtenteils von Spring XML DSL entfernt und bevorzuge jetzt die Verwendung von JavaConfig und Spring Annotations, da Sie eine Überprüfung Ihrer Konfiguration während des Kompilierens und einige Refactoring-Unterstützung erhalten, die Sie nicht benötigen. ' Mit der Spring-XML-Konfiguration kommt man nicht zurecht. In einigen seltenen Fällen habe ich festgestellt, dass JavaConfig/Annotations mit der XML-Konfiguration nicht das tun kann, was verfügbar ist.

Für Hibernate ORM (habe JPA noch nicht verwendet) bevorzuge ich weiterhin die XML-Zuordnungsdateien, da Anmerkungen in Domänenmodellklassen bis zu einem gewissen Grad gegen The Clean Architecture verstoßen, einen Architekturstil für Ebenen, den ich in der Vergangenheit übernommen habe ein paar Jahre. Die Verletzung tritt auf, weil der Core Layer von persistenzbezogenen Dingen wie Hibernate- oder JPA-Bibliotheken abhängig sein muss und die POJOs des Domain-Modells etwas weniger persistent sind. Tatsächlich sollte der Core Layer überhaupt nicht von einer anderen Infrastruktur abhängen.

Wenn The Clean Architecture jedoch nicht Ihre "Tasse Tee" ist, kann ich feststellen, dass die Verwendung von Hibernate/JPA-Annotationen in Domänenmodellklassen gegenüber separaten XML-Zuordnungsdateien durchaus Vorteile (z. B. Bequemlichkeit und Wartbarkeit) bietet.

1
whitestryder

Dies ist die klassische Frage "Konfiguration versus Konvention". Der persönliche Geschmack bestimmt in den meisten Fällen die Antwort. Ich persönlich bevorzuge jedoch die Konfiguration (d. H. XML-basiert) gegenüber der Konvention. IMO-IDEs sind robust genug, um einige der häufig mit dem Aufbau und der Pflege eines XML-basierten Ansatzes verbundenen Probleme zu lösen. Am Ende überwiegt auf lange Sicht der Nutzen der Konfiguration (wie das Erstellen von Dienstprogrammen zum Erstellen, Verwalten und Bereitstellen der XML-Konfigurationsdatei) die Konvention.

1
Jason