Hallo,

schaut mal hier:
http://in.relation.to/servlets/files...am?fileId=2293

Gruß Tom

Nett, aber wenn ich den Annotationswald auf Folie 43 sehe, wir mir ehrlich gesagt schlecht. Sowas ist für Anwendungen in Tutorialgröße vielleicht nett, skaliert aber nicht... von daher - nettes Spielzeug

REINHAUN!

Hallo,

warum sollte sowas nicht skalieren?

Gruß Tom

Skalieren nicht im Sinne der Performance sondern der Wartbarkeit. Ich hab auf dem JavaForum in Stuttgart anfang des Jahres einen Vortrag zu Seam/JSF gesehen, da waren am Ende mehr Annotationen als Codezeilen. Wie gesagt... das tut bis zu einer gewissen größe, da man sich viele Artefakte spart, aber die Vorstellung in einer Domänenklasse (! - die ich evtl. mal in einem anderen Kontext wiederverwenden will) OR Mapping Informationen, Validierung plus eventuell SecurityConstraints zu haben, macht mir schon Angst. Zumal sich mit dieser Vermischung der Concerns auch meist die Anzahl der Leute erhöht, die parallel an einer Klasse arbeiten.

Vielleicht bin ich auch ein wenig biased, aber ich werd wohl nie ein großer Freund von Annotationen.

Gruß
Ollie

Hallo,

Skalieren nicht im Sinne der Performance sondern der Wartbarkeit.

Wollte schon gerade anfangen Annotations mit RetentionPolicy.Runtime sind zur Laufzeit ganz einfache dynamic proxies.
Für den DynamicProxy wird pro Annotation zur Laufzeit ein Klasse gebaut was relativ fix geht deshalb fällt das hier nicht so ins Gewicht

Mal ne kleine Spielerei dazu:
http://www.tutorials.de/forum/java/2...t-aendern.html

Wie gesagt... das tut bis zu einer gewissen größe, da man sich viele Artefakte spart, aber die Vorstellung in einer
Domänenklasse (! - die ich evtl. mal in einem anderen Kontext wiederverwenden will) OR Mapping Informationen,
Validierung plus eventuell SecurityConstraints zu haben, macht mir schon Angst.

Ich stimme dir zu, dass es in manchen Projekten problematisch werden kann, wenn man wirklich jeden Aspekt mit Annotations
abhandelt. Insbesondere deployment-abhängige OR-Mapping Informationen gehören auch für mich ganz klar in eine externe
Konfigruation. Bei Validierungs-Annotations sehe ich das schon ein wenig anders. Je nach Ansichtsweise kann man Valdierung
schon als Teil der Geschäftslogik / BusinessRules sehen die man natürlich mit der einzelnen Komponente auch gleich mit testen
möchte. Deshalb finde ich es legitim das über Annotations zu lösen. Bezüglich Security denke ich das man auch hier zwischen allgemeinen
und vom deployment abhängigen Informationen unterscheiden muss. Wenn ich nun eine Methode allgemein mit @Secure deklariere
sollte ist das für mich ein Teil der Dokumentation. Die deployment spezifische Information, dass diese Methode nur mit
bestimmten Credentials (Der aktive User hat die Rolle Admin) ausgeführt werden soll sollte IMHo wieder in einer externen
Konfiguration landen.
Der Aspekt der Codedokumentation ist gerade bei Projekten die Dependency Injection verwenden IMHO sehr wichtig.
Deshalb finde ich den Ansatz von von google guice Elemente die über DI bevölkert werden (können) mit @Inject zu versehen sehr praktisch.
Vielleicht wär das noch ein schickes feature für die Spring IDE. Direkt im Java Code Editor zu zeigen / highlighten welche
Elemente per Spring Konfiguriert werden und welche nicht. Bisher muss man dafür (AFAIK) in die SpringBeans View schalten.

Ansonsten gibts IMHO keine Probleme wenn man eine mit "unnötigen" Annotations ausgestatte Klasse in anderem Kontext verwendet.
Der Verwender sieht die Annotations ja nicht (zumindest nicht ohne Reflection, oder durch an Framework was die Annotations interpretiert)

Zumal sich mit dieser Vermischung der Concerns auch meist die Anzahl der Leute erhöht, die parallel an einer Klasse arbeiten.

Wie gesagt das tritt nur dann auf wenn Deployment Aspekte über annotations in den Code gelangen. Wenn man dies vermeidet hat man dieses
Problem IMHO nicht.

Gruß Tom

Hier gibt es noch ein schickes Video zu Seam:
http://video.google.com/videoplay?do...19232322118868
Ich habs leider noch nicht gesehen. Es wird im Zweifelsfall genau die Präsentation sein.

Viel Spaß damit.