Ich arbeite an einem Projekt, in dem wir mehrere Attribute in AssemblyInfo.cs haben, die an Methoden einer bestimmten Klasse gesendet werden.
%Vor%Was mir nicht gefällt, ist, dass es eine gewisse Logik in AssemblyInfo steckt ( Info , wohlgemerkt!), die für Anfänger überhaupt keine Logik enthalten sollte. Der schlimmste Teil davon ist, dass die tatsächliche MyClass.cs das Attribut nirgendwo in der Datei hat, und es ist völlig unklar, dass Methoden dieser Klasse sie möglicherweise haben. Aus meiner Sicht tut es der Lesbarkeit des Codes sehr weh (ganz zu schweigen davon, dass die übermäßige Verwendung von PostSharp das Debuggen zu einem Albtraum machen kann.) Besonders, wenn Sie mehrere Multicast-Attribute haben.
Was ist die beste Vorgehensweise hier? Benutzt jemand da draußen PostSharp-Attribute?
Lassen Sie mich zuerst auf Max antworten: Tatsächlich sind Aspekte keine Alternative für gute OOP-Muster. Sie sind ein Komplement . Jedes gute AOP-Design beginnt mit einem guten OOP-Design. Aber OOP-Muster zwingen Sie manchmal dazu, eine Menge Sanitär-Code manuell zu schreiben. In diesen Fällen können Aspekte verwendet werden, um die Implementierung des OOP-Musters zu automatisieren nicht , um sie zu ersetzen.
Wenn Sie AOP intelligent verwenden, kann Ihre Lösung leichter verständlich werden (Geschäftscode wird nicht mit Wartungscode gemischt), um zu testen (Sie können den Aspekt unabhängig vom Geschäftscode testen, dh Sie müssen diesen nicht testen Business-Methode verfolgt ordnungsgemäß), ändern (Sie müssen nur den Aspekt ändern, wenn Sie das Muster ändern möchten, anstatt jede Implementierung des Musters zu ändern). Nun, wenn Sie AOP missbrauchen, wenn Sie es als ein Hacker-Tool verwenden, wenn Sie nicht zuvor in Bezug auf OOP-Muster denken, dann werden Sie mehr Kosten als Vorteile von AOP bekommen. Wie jedes scharfe Werkzeug sollte AOP intelligent verwendet werden.
Zurück zur ursprünglichen Frage.
Wer sagt, dass Sie Aspekte in AssemblyInfo.cs einfügen sollten? Sie könnten eine neue Datei namens GlobalAspects.cs erstellen und alle Aspekte auf Baugruppenebene dort ablegen. Sie haben Recht, dass AssemblyInfo.cs nur für Metadaten auf Baugruppenebene verwendet werden sollte.
Aber wie du mag ich keine Aspekte auf der Montageebene. Ich denke, dass es vermieden werden sollte. Das Hauptproblem bei Assembly-Level-Aspekten ist, dass sie sich auf Namenskonventionen stützen, und das ist böse. (Dieses Übel wird in der akademischen AOSD-Gemeinschaft pointcut fragility genannt.) Wenn Sie eine Klasse oder einen Namespace umbenennen, ändern Sie die Menge der Methoden, auf die sich der Aspekt bezieht, und dies kann schnell zum Albtraum werden . Aus diesem Grund verwende ich nie Aspekte, die auf Namenskonventionen basieren.
Was ist mit der Lesbarkeit des Codes? Ich denke, lesbarer Code ist größtenteils ein kurzer Code. Wenn ich eine Geschäftsmethode CreateProduct habe, möchte ich wahrscheinlich nur den Code sehen, der das Produkt erstellt. Meistens interessiert mich kein Code, der Transaktionen, Ausnahmen oder Tracing behandelt. Es ist genug, wenn ich weiß, dass einige Aspekte das für mich erledigen.
Und woher weiß ich das? Mit PostSharp haben Sie die Visual Studio Erweiterung. Mit AspectJ haben Sie das AspectJ Plug-in für Eclipse (AJDT). Sie zeigen Ihnen innerhalb der IDE, welche Aspekte auf den aktuell angezeigten Code angewendet werden. Und wenn Sie wirklich Details sehen wollen (aber Sie wirklich selten wollen), können Sie den Debugger verwenden, um in Aspekte zu kommen, oder Reflector verwenden, um produzierten Code zu sehen.
Zusammenfassung:
Ich bin mir sicher, dass dies eine unpopuläre Antwort sein wird, aber vielleicht kann ich mein Gruppenzwang Abzeichen bekommen ...
Dein Instinkt ist richtig. Logik in Metadaten jeglicher Art zu setzen, ist eine schreckliche, schreckliche Sünde, für die man ewig im Höllenfeuer der Unerreichbarkeit brennt.
Ich meine damit keine Respektlosigkeit, obwohl ich mir sicher bin, dass es anders interpretiert wird.
Die beste Vorgehensweise wäre, keine "Aspect-ordeded" -Programmierungswerkzeuge zu verwenden, bei denen es sich um Krücken handelt, die die Lahmheit schlechter Entwurfs- und Testpraktiken ermöglichen. Schauen Sie sich stattdessen Ihr Design an und fragen Sie sich, warum.
Warum habe ich das Bedürfnis, dies zu benutzen? Werkzeug? Welches Designproblem war ich? versuchen zu lösen?
Sobald Sie das Problem fest im Griff haben, gehen Sie zu den Design Patterns Explained (Shalloway & amp; Trott) oder Head First Design Patterns (Freeman, Robson, Bates) , und Sierra).
Am Ende wird eine musterorientierte Lösung leichter zu verstehen, leichter zu testen und einfacher zu ändern sein. Die einzigen zusätzlichen Kosten sind die einmalige Gebühr für die Beherrschung von Designmustern anstelle der wiederkehrenden Belastung, herauszufinden, wo all diese Aspekte liegen, wie sie zusammenpassen und wie sie sich bei jeder Veränderung gegenseitig beeinflussen.