Warum einen Post-Compiler verwenden?

AOP (PostSharp) dient zum Anfügen von Code an alle möglichen Punkte in Ihrer Anwendung von einem Ort aus, so dass Sie ihn dort nicht platzieren müssen.

Sie können nicht erreichen, was PostSharp mit Reflection machen kann.

Ich persönlich sehe keinen großen Nutzen in einem Produktionssystem, da die meisten Dinge auf andere, bessere Art und Weise (Protokollierung usw.) erledigt werden können.

Vielleicht möchten Sie die anderen Themen zu diesem Thema überprüfen:

• Jeder mit Postsharp Erfahrung in der Produktion?
• Anders als Protokollierung und Transaktionsverwaltung Was sind einige praktische Anwendungen von AOP?
• Aspektorientierte Programmierung: Wofür verwenden Sie PostSharp?
• usw. (Suche)

Versuchen wir, einen architektonischen Punkt zu diesem Thema zu nehmen. Angenommen, Sie sind Architekt (jeder möchte Architekt sein)  Sie müssen die Architektur Ihrem Team liefern: eine ausgewählte Sammlung von Bibliotheken, Architekturmustern und Entwurfsmustern. Als Teil Ihres Designs sagen Sie: "Wir werden Caching mit folgendem Design-Muster implementieren:"

Dies ist ein korrekter Weg zur Verfolgung. Entwickler werden dieses Muster tausendfach implementieren, also schreiben Sie ein schönes Word-Dokument, in dem Sie erfahren, wie das Muster implementiert werden soll. Ja, ein Word-Dokument. Hast du eine bessere Lösung? Ich fürchte, du tust es nicht. Klassische Codegeneratoren werden nicht helfen. Funktionale Programmierung (Delegierte)? Es funktioniert ziemlich gut für einige Aspekte, aber nicht hier: Sie müssen Methodenparameter an das Muster übergeben. Also, was ist übrig? Beschreibe das Muster in natürlicher Sprache und vertraue darauf, dass Entwickler sie implementieren.

Was wird passieren?

Zuerst schauen sich einige Junior-Entwickler den Code an und sagen "Hm. Zwei Cache-Lookups. Irgendwie nutzlos. Eins ist genug." (Das ist kein Witz - fragen Sie das DNN-Team nach diesem Problem). Und deine Muster sind nicht mehr threadsicher.

Wie stellen Sie als Architekt sicher, dass das Muster richtig angewendet wird? Stückprüfung? Fair genug, aber Sie werden Threading-Probleme auf diese Weise kaum erkennen. Code-Review? Das ist vielleicht die Lösung.

Nun, was entscheiden Sie, das Muster zu ändern? Zum Beispiel, Sie erkennen einen Fehler in der Cache-Komponente und entscheiden, Ihre eigenen zu verwenden? Werden Sie Tausende von Methoden bearbeiten? Es ist nicht nur Refactoring: Was ist, wenn die neue Komponente eine andere Semantik hat?

Was ist, wenn Sie entscheiden, dass eine Methode nicht mehr im Cache gespeichert wird? Wie schwer wird es sein, Caching-Code zu entfernen?

Die AOP-Lösung (unabhängig vom Framework) hat die folgenden Vorteile gegenüber normalem Code:

1. It reduziert die Anzahl der Codezeilen .
2. Es reduziert die Kopplung zwischen Komponenten . Daher müssen Sie nicht viel ändern, wenn Sie die Protokollierungskomponente ändern (aktualisieren Sie einfach den Aspekt). Daher verbessert die Kapazität Ihres Quellcodes, um im Laufe der Zeit neue Anforderungen zu erfüllen .
3. Da es weniger Code gibt, ist die Wahrscheinlichkeit von Fehlern für eine bestimmte Menge von Features geringer, daher verbessert AOP die Qualität Ihres Codes .

Wenn Sie also alles zusammenfügen:

Aspekte reduzieren sowohl die Entwicklungskosten als auch die Wartungskosten von Software.

Ich habe ein 90-minütiges Gespräch zu diesem Thema und Sie können es bei Ссылка ansehen.

Auch hier sind die architektonischen Vorteile von AOP unabhängig von dem gewählten Framework. Die Unterschiede zwischen den Frameworks (auch in diesem Video diskutiert) beeinflussen hauptsächlich das Ausmaß, in dem Sie AOP auf Ihren Code anwenden können, was nicht der Punkt dieser Frage war.

Nehmen wir an, Sie haben bereits eine Klasse, die gut entworfen, gut getestet usw. ist. Sie möchten auf einige der Methoden leicht ein Timing hinzufügen. Ja, Sie könnten Dependency Injection verwenden, eine Decorator-Klasse erstellen, die zwar dem Original entspricht, aber für jede Methode das Timing hat - aber selbst diese Klasse wird ein Chaos der Wiederholung sein ...

... oder Sie können der Mischung Reflektion hinzufügen und einen dynamischen Proxy mit einer Beschreibung verwenden, mit dem Sie den Timing-Code einmal schreiben können, aber Sie müssen diesen Reflection-Code genau richtig einstellen - was nicht so einfach ist wie es könnte sein, besonders wenn Generika beteiligt sind.

... oder Sie können jeder Methode, die Sie zeitlich bestimmen möchten, ein Attribut hinzufügen, den Timing-Code einmal schreiben und ihn als Post-Compile-Schritt anwenden.

Ich weiß, was mir eleganter erscheint - und deutlicher beim Lesen des Codes. Es kann sogar in Situationen angewendet werden, in denen DI nicht geeignet ist (und es ist wirklich nicht für jede einzelne Klasse in einem System geeignet) und ohne andere Änderungen an anderen Stellen.

Aspekte nehmen alle Kopien & amp; Einfügen - Code und schnelles Hinzufügen neuer Funktionen.

Ich hasse nichts mehr als zum Beispiel das gleiche Stück Code immer und immer wieder schreiben zu müssen. Gael hat ein sehr schönes Beispiel für INotifyPropertyChanged auf seiner Website (www.postsharp.net).

Genau dafür ist AOP da. Vergessen Sie die technischen Details, implementieren Sie einfach, wonach Sie gefragt werden.

Auf lange Sicht sollten wir uns alle von der Art und Weise verabschieden, wie wir jetzt Software schreiben. Es ist langwierig und einfach dumm, Code zu schreiben und manuell zu iterieren.

Die Zukunft gehört dem deklarativen, funktionalen Stil, der von einem objektorientierten Rahmenwerk zusammengehalten wird - und die bereichsübergreifenden Anliegen werden von Aspekten gehandhabt.

Ich schätze, die einzigen Leute, die es nicht bald bekommen werden, sind die Leute, die immer noch für Codezeilen bezahlen.