Annotation Driven ?

[rico]

Hi,

Worin liegt der Vorteil in der Verwendung von Annotations bei der Konfiguration von Spring-Komponenten oder Hibernate-Mappings, abgesehen von der zusätzlichen Konfigurationsdatei ?
Momentan sehe ich eher ein paar Nachteile:

• 
  - Unübersichtlichkeit
  - größerer Aufwand beim Austausch von Komponenten
  - ...

Kann mir jemand weiterhelfen ?

LG rico

 

[kama]

Hi,

Worin liegt der Vorteil in der Verwendung von Annotations bei der Konfiguration von Spring-Komponenten oder Hibernate-Mappings, abgesehen von der zusätzlichen Konfigurationsdatei ?

Also zum Thema Spring kann ich wenig sagen, aber im Bereich Hibernate....

Momentan sehe ich eher ein paar Nachteile:

• 
  - Unübersichtlichkeit
  - größerer Aufwand beim Austausch von Komponenten
  - ...

Wo ist denn die Unübersichtlichkeit bei Hibernate ? Ich habe eine Datei (Java Klasse) mit den Annotierungen wo alles drin steht was ich brauche....einfach und übersichtlicher gehts nicht....

Vorher OHNE Annotations: Immer zwei Dateien Pflegen und vor allem Synchron halten.....hat man über XDoclet gemacht ist auch nicht wirklich gut....

Und wenn ich Komponenten austausche, dann ist ja alles dabei...am besten noch über ein Maven Repository....wo ist das Problem ?

MfG
Karl Heinz Marbaise

 

[tfa]

Annotations sind natürlich übersichtlicher als XML. Aber alles, was geht, annotieren sollte man auch nicht. Gerade Dinge, die zur Konfiguration gehören (Connections, Name des Datenbankschemas) hält man lieber in Config-Dateien, ob jetzt XML oder nicht.
Hibernate-Mappings gehören zum Datenmodel und können ruhig annotiert werden.

 

[rico]

Vorher OHNE Annotations: Immer zwei Dateien Pflegen und vor allem Synchron halten....

Das stimmt allerdings. Jedoch erweitere ich doch dann die einfachen "Daten-POJO's", um Implementierungsdetails. (Hibernate-Imports,Hibernate spezifische Metainformationen).
Dies macht eine Austauschbarkeit der Datenschicht relativ schwierig, wenn die Datenobjekte über alle Layer hinweg verwendet werden.

LG
rico

 

[tfa]

Das meiste lässt sich über JPA-Annotationen (javax.persistence.*) erledigen, damit machst du dich nicht von einer Implementierung abhängig.

Außerdem kannst du dir Interfaces definieren und gegen die entwickeln. Du hast dann z.B. das Interface DatenPojo und die Klasse DatenPojoHibernateImpl. Die Implementation lässt sich dann leicht austauschen. Darüber hinaus gibt es noch andere Vorteile, wenn du z.B. eine Client/Server-Architektur hast.

 

[foobar]

Der Vorteil von Annos gegenüber XML-Hell ist auch die bessere Validierung. Man weiß genau auf welche Property/Methode sich die Anno bezieht.
Eine Kombination von Annos für das Mapping und XML für Connection und sowas finde ich persönlich am übersichtlichsten.

 

[byte]

Finde Annotations auch angenehmer, nicht zuletzt weil sie refactoring-freundlicher sind.

 

[rico]

Hi,

Das meiste lässt sich über JPA-Annotationen (javax.persistence.*) erledigen, damit machst du dich nicht von einer Implementierung abhängig.

Ich hätte dabei aber das Problem, dass ich keine Hibernate spezifischen Annotations verwenden dürfte.

Außerdem kannst du dir Interfaces definieren und gegen die entwickeln

Klar, das kann man schon machen, jedoch braucht man dann noch eine implementierungsabhängige Factory die die verschiedenen Entity-Objekte erzeugt.


LG rico

 

[byte]

Ich hätte dabei aber das Problem, dass ich keine Hibernate spezifischen Annotations verwenden dürfte.

Wenn Du keine solche Abhängigkeiten in der Implementierung Deines Modells haben willst, dann bleibt nur der Weg über die XML-Konfiguration.
Für mich persönlich stehen die Schnittstellen des Modells im Vordergrund, also die Interfaces. Diese sollten keine Abhängigkeiten zu irgendwelchen Frameworks haben. Bei der Implementierung sehe ich das recht locker. In den meisten Fällen wird man das Persistenzframework eh nie ändern.

Außerdem kannst du dir Interfaces definieren und gegen die entwickeln

Klar, das kann man schon machen, jedoch braucht man dann noch eine implementierungsabhängige Factory die die verschiedenen Entity-Objekte erzeugt.

Ja, aber es ist doch schon ein Unterschied, ob ich an 1 Stelle die Implementierung injiziere und überall sonst nur nach Interfaces programmiere oder ob ich an N Stellen im Code direkt die Implementierung fest verdrahte.