Was sind die Vor-/Nachteile von Annotationen (Nicht-Compiler) im Vergleich zu XML-Konfigurationsdateien?

Question

Wenn ich mir Java-Frameworks wie Hibernate, JPA oder Spring anschaue, habe ich normalerweise die Möglichkeit, meine Konfiguration über eine XML-Datei oder Setze Anmerkungen direkt in meine Klassen ein.

Ich frage mich ständig, auf welche Weise ich gehen soll.

Wenn ich Annotationen verwende, habe ich die Klasse und ihre Konfiguration zusammen, aber mit einem xml bekomme ich ein größeres Bild von meinem System, weil ich alle Klassenkonfigurationen sehen kann.

Anmerkungen werden auch irgendwie kompiliert, ich denke, und es sollte schneller sein als das Parsen der XML, aber auf der anderen Seite, wenn ich meine Konfiguration ändern möchte, muss ich es neu kompilieren, anstatt nur die XML-Datei zu ändern könnte für Produktionsumgebungen auf Kundenseite noch praktischer werden).

Also, wenn ich auf meine Punkte schaue, tendiere ich dazu, den xml-Weg zu gehen. Aber beim Betrachten von Foren oder Tutorials werden normalerweise Anmerkungen verwendet.

Was sind Ihre Vor- und Nachteile?

Answer 1

Eine gute Faustregel: Alles, was Sie sehen können, ohne eine vollständige Umschichtung ändern zu wollen (z. B. Anpassung von Leistungsparametern), sollte wirklich in etwas "Soft-konfigurierbar" wie eine XML-Datei gehen. Alles, was sich niemals realistisch ändern wird - oder nur in der Situation, in der Sie den Code sowieso ändern müssen - kann vernünftigerweise in einer Anmerkung enthalten sein.

Ignorieren Sie irgendwelche Ideen der Leistungsunterschiede zwischen Anmerkungen und XML - es sei denn, Ihre Konfiguration ist absolut massiv der Unterschied wird unbedeutend sein.

Konzentrieren Sie sich auf Flexibilität und Lesbarkeit.

Answer 2

Wenn Sie eine API schreiben, dann ein Wort der Warnung: Anmerkungen können in Ihre öffentliche Schnittstelle austreten, was unglaublich ärgerlich sein kann.

Ich arbeite derzeit mit APIs, wo der API-Anbieter seine Implementierung mit Spring MBean Annotationen gespickt hat, was plötzlich bedeutet, dass ich eine Abhängigkeit von den Spring-Bibliotheken habe, trotz der Möglichkeit, Spring überhaupt nicht zu brauchen :(

(natürlich, wenn Ihre API eine Erweiterung Feder selbst ist, könnte dies eine gültige Annahme.)

Answer 3

ich denke, die Entscheidung kommt zu ‚Lebenszyklus‘, und Impedance Mismatch zwischen Lifecycles.

Lebenszyklus: Jedem Datenelement, ob Quellcode, Datenbankzeile, kompilierte Klasse oder Objekt, ist ein Lebenszyklus zugeordnet. Wann entsteht es und wann wird Müll gesammelt?

Angenommen, ich setze Hibernate-Annotationen in eine Java-Klasse. Scheint eine vernünftige Idee zu sein, besonders wenn ich eine neue Datenbank von Grund auf erstelle und zuversichtlich bin, dass nur diese eine Anwendung jemals eine Verbindung zu ihr herstellen wird - die Lebenszyklen meiner Klassen, das Datenbankschema und das ORM Mapping sind natürlich synchron.

Nun nehme ich an, ich möchte die gleiche Klasse in einer API verwenden und sie an Dritte weitergeben. Die Hibernate-Anmerkungen gehen in meine API ein. Dies geschieht, weil der Lebenszyklus dieser Klasse und der Datenbank nicht identisch sind. Daher verwenden wir Mapping-Tools, um zwischen Schichten von Beans in einem System zu übersetzen.

Ich versuche, über Lebenszyklen nachzudenken, und dass Annotationen, die zu Lebenszyklus-Mismatches führen können, vermieden werden sollten. Einige Anmerkungen sind in dieser Hinsicht relativ harmlos und einige sind eine versteckte Gefahr.

Beispiele für ungültige Anmerkungen: ORM-Zuordnung, Datenbankkonfiguration, fest codierte Konfiguration für Elemente, die zwischen Implementierungsumgebungen variieren können, Validierungen, die je nach Kontext variieren können.

Beispiele für harmlose Anmerkungen: REST-Endpunktdefinitionen, JSON/XML-Serialisierung, Validierungen, die immer zutreffen.