L'ultima sessione che ho seguito è stata la
BOF013, intitolata
"Aspect-Oriented Programming and .NET": il tema trattato è sicuramente interessante, e batte un terreno ancora quasi inesplorato dalla piattaforma .NET; sostanzialmente, gli "aspetti" forniscono la possibillità di definire del codice "genericamente utile" (logging, tracing, security, ...) in modo indipendente dal contesto di utilizzo, al fine di poterlo poi applicare in maniera poco invasiva al codice applicativo (i puristi della AOP mi perdonino la brutalità della definizzione). Il pensiero di molti di voi sarà sicuramente corso alle classi attributo: ebbene, esse non necessariamente rappresentano un esempio di AOP poichè è tipicamente un agente esterno (es: XmlSerializer) ad eseguire il codice in funzione degli attributi rilevati mediante l'uso delle tecniche di Reflection. AOP permette invece di "iniettare" direttamente il codice sottointeso dall'attributo. Esistono alcuni progetti indipendenti da Microsoft (e tipicamente a codice aperto) per dotare C# di capacità AOP, ma quello che mi è chiaro è che non esiste ancora una strategia architetturale ritenuta "ottimale" per farlo. Tra le tecniche usate, esiste quella della espansione "macro-like" (alla
AspectJ, per intenderci), che lavora processando il codice prima che sia compilato, in modo da iniettare nel nostro sorgente anche il codice sottointeso dagli aspetti: è una strategia funzionale, ma che rende arduo il debugging, poichè i numeri di riga del codice applicativo non coincidono con quelli del codice effettivamente in esecuzione. La seconda strategia prevede l'uso dei
ContextAttribute di .NET, che permettono di effettuare la interception dell'accesso ai membri esposti da un oggetto a runtime: questo è un approccio "a la MTS/COM+", e se ne temono gli impatti in termini di performance. Infine, l'ultima ipotesi risiede nell'uso delle capacità di
Emitting di codice da parte di
CodeDom per iniettare il codice degli aspetti: il vantaggio di questa tecnica è di poter lavorare sia a tempo di compilazione (come la prima strategia mostrata), sia a runtime. Permane comunque la difficoltà di adattare i tool (in primis il debugger) a disposizione per poter gestire questi scenari. E Microsoft che dice? La percezione è che stia osservando il fermento attorno ad AOP, in attesa di decidere se supportare ufficialmente questo modello. Se son rose...
Technorati Tags: aspect oriented programming
posted @ venerdì 2 luglio 2004 23:22