PostSharp
There are 6 entries for the tag
PostSharp
Tempo fa ho introdotto PostSharp, dal primo approccio è passato ormai un anno e da qualche mese lo uso con soddisfazione, in produzione, per la gestione della parte noiosa del tracing. In questi giorni ho ripreso in mano la parte di AOP per la validazione dei parametri di input di un metodo, tipicamente quello che si fa è questo: void StandardValidation( String v )
{
if( v == null )
{
throw new ArgumentNullException( "v" );
}
}
oppure, evolvendosi...
Un paio di assiomi ;-): Il Tracing è necessario; Il Tracing è di una noia mortale; Però… ci sono due macro categorie di Tracing in realtà, io divido tra: Tracing: quello che fa il codice: il metodo tal dei tali è stato invocato con la lista di parametrei xyz; Logging: quello che fa l’utente: l’utente ‘mauro’ alla tal ora del tal giorno ha salvato la tal anagrafica cliente; Quello che più mi pesa è la prima categoria, facendo...
per ora è solo un’idea che mi frulla per la testa ma… una cosa che si fa con M-V-VM è la necessità di triggerare la rivalutazione dell’eseguibilità di un ICommand a fronte del fatto che una certa cosa è successa, tipicamente un’altra proprietà del VM è cambiata; un esempio: Il comando “Browse” non è attivo se la casella di testo “Criteri di Ricerca” (in binding con la proprietà QueryText del VM) è vuota, quando la proprietà QueryText cambia dobbiamo triggerare la rivalutazione dell’eseguibilità dell’ICommand. Questo in termini di codice spesso si traduce in qualcose...
Se vado avanti così potrei diventare PostSharp addicted… già sono compiler addicted conclamato, sono sulla buona strada per diventare Unit Testing addicted e dopo aver provato la compile time validation di PostSharp posso asserire che si sta chiudendo il cerchio. Un paio di giorni fa abbiamo visto come usare PostSharp per validare a runtime i parametri di un metodo (per inciso funziona anche con i costruttori) facendo semplicemente una cosa del genere: class MyTestClass
{
public void Foo( [NotNull]String arg )
{
Console.WriteLine( "Foo( String ):...
Mi riallaccio al post di ieri per fare una precisazione, faccio un nuovo post perchè fare un update dell’altro è pressochè impossibile… sopportatemi ;-) Ieri ho detto che: “…quello che però non ha fatto è stato rimettere sul parametro del metodo privato l’attributo, e questo credo sia un bug, vedremo…;” Riferendomi a questa situazione: [ArgumentValidatorAspect()]
class MyTestClass
{
public void Foo( [NotNull]String arg )
{
Console.WriteLine( "Foo:" + arg );
}
}
e compilando il risultato che otteniamo, visto con il fido Reflector, è questo:
...
è 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...