Ich habe mir einige der bekannten AOP-orientierten Frameworks für .Net wie PostSharp, Bltoolkit, Castle, Cecil und Policy Injection Block von Microsoft angeschaut. Vielleicht bin ich ignorant, aber es scheint, dass diese Frameworks nicht die Möglichkeit bieten, Code zu injizieren, während die Klasse von der virtuellen Maschine geladen wird, bevor sie für die Anwendung sichtbar ist. Sie alle scheinen sich auf die Verwendung von Factory- oder Klassen-/Methodenebenenattributen zu verlassen, die die Metadaten bereitstellen, die für die Kompilierungszeitmanipulation von Assemblys benötigt werden. Das kritische Merkmal von java.lang.instrument, das ich suche, besteht darin, Interceptors einfach um Methodenaufrufe zu injizieren, ohne die Quelle (Attribute von Methoden/Klassen) zu ändern oder bestehende Assemblys neu zu erstellen, um den Interceptionscode einzufügen.Gibt es ein .Net-Analogon der von java.lang.instrument bereitgestellten Funktionalität?
Antwort
Sie haben Recht, dass die meisten AOP-Frameworks für .NET das Erstellen von Objekten mit einer speziellen Fabrik oder ähnlichem erfordern. Der Grund dafür ist, dass (benutzerdefinierte) Attribute in .NET passiv sind. Daher benötigen Sie eine Art Framework, mit dem diese Attribute zeitnah überprüft werden können.
Es gibt ein paar AOP-Frameworks für .NET, die entweder Codegenerierung oder IL-Weaving (Änderung des Zwischensprachen-Bytecodes nach normaler Kompilierung) verwenden, um Interception zuzulassen, aber ich bleibe immer weg von solchen Dingen - es gibt eine Menge von inhärenten Problemen in einem solchen Ansatz.
Ich hatte mal die Gelegenheit, Anders Hejlsberg zu fragen, ob wir in .NET keine 'aktiven' Attribute bekommen könnten, aber seine Antwort war, dass Microsoft, wenn eine solche Fähigkeit zur Verfügung stünde, die weitere Entwicklung der Plattform ebenfalls einstellen könnte , weil es unmöglich wäre, .NET nach vorne zu bringen, ohne die Kompatibilität mit dem Code von jemandem zu stören (ich mag seine Antwort falsch darstellen, aber der wesentliche Teil ist, dass es betrachtet und abgelehnt wurde - anscheinend aus guten Gründen).
Das gesagt, .NET hat eine Instrumentation API, die jeden Methodenaufruf abfangen kann. Diese API ist jedoch eine nicht verwaltete API (Sie müssen nicht verwalteten C++ - Code schreiben) und (IIRC) erfordert, dass Sie die .NET-Anwendung selbst hosten. Es ist ein sehr grober Ansatz. Sie sollten sich darüber im Klaren sein, dass die Instrumentierung die Leistung Ihrer Anwendung potenziell beeinträchtigen kann.
Kennen Sie diese Zuschreibung: comparing IoC frameworks?
Ich hatte gehofft, die unmanaged API zu vermeiden. Danke für die interessanten Informationen! –