è da un po’ di tempo che mi riprometto di fare delle prove e capire come funziona il gioiellino. Diciamo che sono partito con una necessità decisamente triviale ma che illustra bene le potenzialità della cosa. Lo scopo è far funzionare questo codice: class MyTestClass
{
public void Foo( [NotNull]String arg )
{
Console.WriteLine( "Foo:" + arg );
}
}
e fare in modo di ottenere una ArgumentNullException( ‘arg’ ) se il metodo Foo() viene invocato così:
MyTestClass obj = new MyTestClass();
obj.Foo( null );
Nello specifico NotNullAttribute è un normalissimo attributo .net, senza nulla di particolare:
[AttributeUsage( AttributeTargets.Parameter )]
public class NotNullAttribute : Attribute
{
}
questo è un tipico scenario in cui AOP (Aspect Oriented Programming) ci può essere di grandissimo aiuto, una implementazione dei paradigmi AOP per .net è formita proprio da PostSharp; partiamo dal codice che è più semplice:
[Serializable]
public class ArgumentValidatorAspect : OnMethodInvocationAspect
{
public override void OnInvocation( MethodInvocationEventArgs context )
{
context.Proceed();
}
}
definiamo una nostra classe che deriva da OnMethodInvocationAspect, classe definita nel framework di PostSharp, e ci limitiamo a fare l’override del metodo OnInvocation().
Due cose sono degne di nota:
- la nostra classe è a tutti gli effetti un attributo: OnMethodInvocationAspect infatti alla lontana deriva da Attribute;
- la nostra classe deve essere marcata con l’attributo Serializable, vedremo di seguito il motivo, e questo comporta tutta una serie di possibili problematiche e di considerazioni che devono essere fatte quando si sviluppa un “Aspect” con PostSharp;
Fatto ciò possiamo fare una cosa molto interessante:
[ArgumentValidatorAspect()]
class MyTestClass
{
public void Foo( [NotNull]String arg )
{
Console.WriteLine( "Foo:" + arg );
}
}
possiamo decorare la nostra classe di test con l’attributo appena definito. Possiamo quindi realizzare una semplice applicazione console che testa il tutto:
class Program
{
static void Main( string[] args )
{
MyTestClass tc = new MyTestClass();
tc.Foo( "Hello World!" );
}
}
Una volta che abbiamo configurato Visual Studio per “usare” PostSharp, vedremo dopo cosa comporta, possiamo compilare il nostro semplicissimo progetto e premere F5 quello che otteniamo è esattamente quello che ci asspettiamo:
Se però siamo curiosi e andiamo ad indagare con Reflector che cosa contiene il nostro assembly scopriamo delle cose decisamente interessanti:
La nostra classe infatti contiene qualcosa che non ci aspetteremmo di trovare: contiene il metodo pubblico Foo() che abbiamo definito noi e contiene anche un metodo privato ~Foo(), se andiamo a vedere il corpo dei metodi scopriamo che il nostro codice sta nel metodo privato e non in quello pubblico:
Che cosa è successo? la cosa è abbastanza semplice:
- il primo step è quello di configurare Visual Studio aggiungendo al progetto i target di MSBuild di PostSharp: l’help di PostSharp è decisamente esauastivo nei passaggi da seguire;
- Quando lanciate una build al termine della compilazione vengono invocati i task di PostSharp che in questo caso non fanno altro che:
- disassemblare l’assembly prodotto;
- andare alla ricerca dei tipi marcati con l’attributo “ArgumentValidatorAspect”;
- modificare il codice dei tipi in modo che le chiamate vengano redirette all’aspect;
- istanziare il vostro aspect e serializzarlo, ecco perchè è necessario che sia Serializable, e infine salvare l’aspect serializzato nelle risorse;
- rigenerare l’assembly e completare la build;
A runtime succede che quando invocate il metodo Foo() in realtà state invocando il nuovo metodo Foo() che, utilizzando l’aspect deserializzato, è in grado di redirigere la chiamata prima all’aspect e poi dall’aspect verso il vero metodo ~Foo():
- Foo();
- Aspect:
- Aspect –> Proceed();
- ~Foo();
A questo punto penso che anche a voi si sia accesa la lampadine e abbiate detto: mumble mumble… ma se definiamo il nostro attributo così:
[AttributeUsage( AttributeTargets.Parameter )]
public class NotNullAttribute : Attribute
{
public void Validate( ParameterInfo parameter, Object value )
{
if( value == null )
{
throw new ArgumentNullException( parameter.Name );
}
}
}
e il nostro aspect cosà:
[Serializable]
public class ArgumentValidatorAspect : OnMethodInvocationAspect
{
public override void OnInvocation( MethodInvocationEventArgs context )
{
//L'array di valori passati al metodo
object[] values = context.GetArgumentArray();
//Il nome del metodo pubblico: PostSharp genera un metodo private con anteposta la tilde
String publicMethodName = context.Delegate.Method.Name.Substring( 1 );
//Un rifermento al metodo pubblico
MethodInfo mi = context.Delegate.Method.DeclaringType.GetMethod( publicMethodName );
//Lambda, lambda e lambda ;-)
mi.GetParameters()
.Where( pi => pi.IsAttributeDefined<NotNullAttribute>() )
.Select( pi => new
{
Parameter = pi,
Attribute = pi.GetAttribute<NotNullAttribute>(),
Value = values[ pi.Position ]
} )
.ForEach( tupla => tupla.Attribute.Validate( tupla.Parameter, tupla.Value ) );
context.Proceed();
}
}
scopriamo che il seguente codice funziona esattamente come ci aspettiamo:
try
{
MyTestClass tc = new MyTestClass();
tc.Foo( null );
}
catch( ArgumentNullException anex )
{
Console.WriteLine( "Exception: {0}", anex.Message );
}
Producendo questo risultato:
Bingo ;-)
Facciamo un po’ di commenti sul codice dell’apect perchè merita:
public override void OnInvocation( MethodInvocationEventArgs context )
il metodo OnInvocation ci passa un’istanza di una classe MethodInvocationEventArgs che ci da accesso a tutte le informazioni relative al metodo che stiamo intercettando, attenzione che qui c’è uso di reflection, ma:
- a detta dell’autore viene usata una ed una sola volta e poi le informazioni cachate;
- nelle versioni future molte parti stanno per essere sostituite con generazione di codice MSIL custom in fase di build per superare le problematiche di performance di reflection a runtime;
//L'array di valori passati al metodo
object[] values = context.GetArgumentArray();
//Il nome del metodo pubblico: PostSharp genera un metodo private con anteposta la tilde
String publicMethodName = context.Delegate.Method.Name.Substring( 1 );
//Un rifermento al metodo pubblico
MethodInfo mi = context.Delegate.Method.DeclaringType.GetMethod( publicMethodName );
Le informazioni che possiamo quindi recuperare sono ad esempio:
- l’array dei valori dei parametri in ingresso al metodo: e qui possiamo comiciare ad immaginarci tutti gli scenari di logging e tracing semiautomatico…;
- un’istanza della classe MethodInfo che ci da accesso a tutte le informazioni sul metodo chiamato. Come probabilmente avrete notato il codice fa un’operazione apparentemente strana:
- abbiamo decorato il parametro con l’attributo “NotNull”;
- PostSharp in fase di build ha rinominato il nostro metodo trasformandolo in privato e anteponendo al nome la tilde;
- quello che però non ha fatto è stato rimettere sul parametro del metodo privato l’attributo, e questo credo sia un bug, vedremo…;
- quindi in questo momento quello che dobbiamo fare per recuperare il nostro parametro è un giro un po’ arzigogolato:
- recuperare prima il nome del metodo pubblico: quello privato senza la tilde;
- recuperare un riferimento al metodo pubblico;
- cercare l’eventuale presenza dei parametri e invocare la validazione;
mi.GetParameters()
.Where( pi => pi.IsAttributeDefined<NotNullAttribute>() )
.Select( pi => new
{
Parameter = pi,
Attribute = pi.GetAttribute<NotNullAttribute>(),
Value = values[ pi.Position ]
} )
.ForEach( tupla => tupla.Attribute.Validate( tupla.Parameter, tupla.Value ) );
Facendo uso di un po’ di sane Lambda e di fluent interface riusciamo a scrivere anche del codice elegante per la validazione, anche qui potremmo fare alchimie notevoli per renderlo ulteriormente flessibile magari introducendo un attributo di base ma non è oggetto del nostro test ;-). ndr: ForEach(), IsAttributeDefined() e GetAttribute() sono degli extension methods miei.
Le potenzialità sono notevoli, quello che si pò fare si può certamente fare anche in altri mille modi uno su tutti usando ad esempio i concetti di facility e interception messi a disposizione dai framewrok di inversion of control ma in questo caso con il vincolo che il componente che volete intercettare sia gestito dal framewrok di IoC e questo non è detto che sia possibile.
PostSharp ci mette ad disposzione un modello che ci consente di fare intercept anche di qualcosa che non abbiamo scritto noi:
[assembly: MyOnMethodInvocationAspect(
AttributeTargetAssemblies = "mscorlib",
AttributeTargetTypes = "System.Threading.*" )]
mi limito a riportare un semplice e esempio lasciando a voi l’onere/onore di capirne le potenzialità ;-)
Un’altra cosa decisamente interessante che si può fare è usare PostSharp per fare validazione a Compile Time, si avete capito bene a Compile Time ed eventualmente “rompere” la build sulla base di considerazione fatte da vostro codice custom che viene invocato dal compilatore… e questo mi stuzzica decisamente di più ;-)
public class MySampleAspect : OnMethodInvocationAspect
{
public override bool CompileTimeValidate( MethodBase method )
{
Message error = new Message( SeverityType.Error, "ErrorCode", "Error message.", "Error Location" );
MessageSource.MessageSink.Write( error );
return false;
}
}
Interessante, decisamente… qui concentrerò i miei prossimi esperimenti.
.m
