| 

.NET C# Java Javascript Exception

5
Hallo zusammen,

mich würde die Stimmung zum Thema Aspektorientierte Programmierung interessieren. Ich arbeite seit einigen Jahren mit PostSharp und habe gute Erfahrungen damit gemacht. Allerdings habe ich die Aspekte nur in interne Projekten eingesetzt, was sich in Zukunft aber ändern soll. Deshalb würde mich interessieren:

Habt Ihr AOP überhaupt im (Praxis)Einsatz und hat es sich bewährt?
Wenn ja, welches Framework nutzt Ihr, seid Ihr zufrieden?
Wenn nein, was sind die Gründe?

Gruß
Florian
News:
18.07.2011
ffordermaier 8,4k 3 9
Hat sonst niemand Erfahrungen mit AOP Erfahrungen gemacht (es soll hier nicht ausschließlich um PostSharp oder .NET gehen, ganz im Gegenteil...)? Gibt es Gründe, warum jemand sich vlt. auch einfach nicht damit beschäftigen möchte/kann/darf/soll? Weitere Stimmen würden mich sehr interessieren. Danke :-)
ffordermaier 19.07.2011
2 Antworten
3
Ich habe es in einem Projekt für Performance-Logging von Remote-Zugriffen eingesetzt.

Des Weiteren nutze ich AOP für Security und Transaktions-Handling in einem eigenen Projekt.

Als Framework verwendete ich beide Male AspectJ.

Das AOP von Spring soll nicht so mächtig sein als das von AspectJ, Insbesondere Field-Access wird unter Spring nicht unterstützt. Der einzige Vorteil ist, dass man in Spring AOP per XML-Datei konfigurieren kann. Für sehr allgemeine Aufgaben, wie Transaktions-handling und Security ist Spring also gut geeignet. Wenn man sehr flexible Arbeiten möchte und Compiler-Unterstützung wünscht ist das reine AspectJ die bessere Wahl.

Meine Erfahrungen mit AOP sind gut. Das Problem, was ich im Praxis-Einsatz über einfaches Logging und Transaction hinaus sehe ist, dass es an Kompetenzen fehlt, Querschnittsthemen sauber aus dem fachlichen Quellcode herauszuschneiden. Ich würde es nur in einem Projekt einsetzen, wo der Architekt selber tiefe Kenntnisse über AOP hat, damit nicht Infrastrukturcode in Fachklassen verbleibt oder Fachlogik in Aspekte wandert.

In einem Team, was OO lebt, wird man es wesentlich einfacher haben, als in einem Team mit heterogenen Ansichten über das präferierte Programmierparadigma. OO ist schon ziemlich nahe an dem Optimum bzgl. Modularisierung. AOP komplettiert OO in sinnvoller Weise und merzt dessen Schwächen aus. Wenn OO schon kein Thema im Projekt ist, braucht man mit AO nicht anzufangen.
18.07.2011
oopexpert 455 1 8
Danke für Deinen Erfahrungsbericht. Ich stimme Dir zu, wenn OO kein Thema ist, dann liegt das Problem woanders und die Lösung sicher nicht in AOP. Ich denke aber auch, dass die erforderliche Kompetenz, um Aspekte nutzen zu können, niedriger ist, als das orthogonale Belang in aller Vollständigkeit alltäglich in OO abzubilden. Die Identifizierung und Codierung von praxistauglichen Aspekten erfordert mehr Kompetenz, auch da stimme ich Dir zu. Danke auch für die Erfahrungen mit den Frameworks :-)
ffordermaier 18.07.2011
3
Hallo ffordermaier,

siehe auch .net AOP mit PostSharp -> für den Echteinsatz reif genug?

Da du auch fragst warum nicht hier meine Antwort:
Ich verwende es nicht weil (ganz ehrlich) ich mich damit noch nicht richtig befasst habe und weil es den Build-Vorgang ziemlich verlangsamt.
Für Eingabevalidierung verwende ich CodeContracts und zB für den Logging-Aspekt erstelle ich eine neue Klasse die von der anderen erbt und dort das Logging drin ist. ZB
public class Math
{
public virtual int Add(int a, int b)
{
return a + b;
}
}

public class LoggingMath
{
public override int Add(int a, int b)
{
// hier loggen
int result = base.Add(a, b);
// ev. hier loggen
return result;
}
}

So hab ich das getrennt :-) Es ist zwar nicht so wiederverwenbar wie ein Aspekt bei AOP, aber dafür kann spezifischer geloggt werden. Sollte es immer dasselbe sein das geloggt wird dann verwende ich eine statische Methode die das übernimmt.

mfG Gü
18.07.2011
gfoidl 9,4k 3 5
1
(+1!) Erstmal danke für den Link auf die frühere Diskussion. Das mit der Ableitung statt dem Aspekt finde ich eine gute Vorgehensweise, wenn kein AOP eingesetzt wird. Schwieriger wird es da wahrscheinlich bei z.B. Event-Level Aspects. Das mit der längeren Build-Time ist für mich ehrlich gesagt zweitrangig. Zu der verlinkten Diskussion muss ich auch noch anmerken, dass nicht jeder immer grüne Wiese entwickeln kann oder Altsysteme mal eben auf EBC umstellt. Gerade in Altsystemen und Wartungsprojekten kann der gezielte Einsatz von AOP in meinen Augen erheblich Zeit und Kosten sparen.
ffordermaier 18.07.2011
Randbemerkung: mit dem Link hab ich nicht auf EBC abgespielt. EBC haben in meinen Augen ganz andere Nachteile die den Vorteil des "impliziten AOP" mehr als überwiegen. Aber da diese EBC-Diskussion bisher immer sehr länglich war/ist will ich hier nicht darauf eingehen ;-)
gfoidl 18.07.2011
Sollte auch nicht so rüberkommen, sorry. Du gibst immer sehr substantielle Beiträge/Antworten, aus diesem Grund freut es mich, dass Du auch hier beigetragen hast. Ich such mir mal diese EBC Diskussionen raus, interessiert mich was darüber so für Meinungen existieren. Hab mich an sich mit der Thematik noch zu wenig beschäftigt, als dass ich da mitreden könnte. Allerdings hab ich mir letzte Woche die ReactiveExtensions besorgt und irgendwie find' ich das schon cool. Was mir das aber irgendwann mal bringen könnte, auch im kleinen Stil,... großes Fragezeichen?!?
ffordermaier 18.07.2011
Es ist schon richtig rübergekommen - ich wollte es nur trotzdem anmerken. Danke für das Kompliment, das kann ich nur zurückgeben.
"Diese" EBC-Diskussion ist einem internen Forum passiert und deshalb wirts du diese auch nicht finden und ich kann darauf nicht verlinken - sonst hätte ich sie dir nicht vorenthalten. Aber auch Ralf Westphal (der Erfinder von EBC) war daran beteiligt, sie hatte also wirklich Substanz. Ein Zusammenfassung azufertigen könnte ich zwar ist aber aufwändig damit auch nix aus dem Zusammenhang gerissen wird ;-)
gfoidl 18.07.2011
Verstehe ich, wenn Du da interne Diskussionen nicht veröffentlichen kannst. Aber Dein Kommentar läßt darauf schließen, dass Du für Dich selbst bereits ein Fazit zum Thema EBC gezogen hast, das mich brennend interessieren würde. Passt das in nen Kommentar?
ffordermaier 18.07.2011
Nein - um es korrekt darzulegen müsste es wohl umfassender sein und dazu reichen 600 Zeichen bei weitem nicht. Auch bezieht sich dieses Resume auf EBC 1.0 und mittlerweile ist Ralf bei EBC 2.0 und dazu gibt es wieder eine interne Diskussion (auf myCSharp) :-)
Selbst wenn ich meine Meinung hier darlege sehe ich die Gefahr dass es ausarten beginnt. Es ist ja nur meine Meinung - und die von ein paar anderen - und ist nicht absolut. Also würde ein Diskussion losgetreten werden und ich hab momentan nicht die Lust mich an einer solchen zu beteiligen. Bitte um Verständnis.
gfoidl 18.07.2011

Stelle deine Postsharp-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH