StrangeLog - Il blog di Andrea Saltarello

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

Christian Weyer (relatore della sessione) inizia dove Clemens ha terminato ieri: creare Web Services ad alte prestazioni significa innanzitutto abbandonare l'idea che essi implementino un mapping di RPC su HTTP. Anche se la funzionalità "Add Web reference" di Visual Studio può fare pensare che referenziare un WS sia semplicemente dire al CLR: "beh, raggiungi questo assembly tramite http", questo approccio è decisamente sbagliato, e dare la falsa convinzione che si stia invece usando degli oggetti. I Web Services sono basati su messaggi, ed è opportuno progettarne la struttura prima di inziare la codifica: ritrovarsi a piazzare attributi XmlIgnore solo per "correggere" le strutture da restituire al client (e magari evitare problemi di versioning) è un chiaro indice di errata progettazione. Dovremmo inoltre ridurre al minimo necessario il numero di invocazione di web method, inviando i dati necessari al server nella forma più aggregata a disposizione. Aggiungete la "classica" affermazione: "i WS sono una facciata, e non una applicazione. L'applicazione deve essere indipendente e disaccoppiata" ed avrete l'ennesima best practice in materia; nulla di nuovo, insomma, ma certe cose non si ripetono mai abbastanza :-)

E' proprio vero che a TechEd Microsoft mostra tutte le caratteristiche della propria piattaforma, bugs (Bunny) compresi! :-)

E' passato un anno, ma nulla sembra cambiato: sono le sessioni di Clemens Vasters l'argomento che citerei a chi mi chiedesse: "Parchè partecipare a TechEd (con tutto quello che costa)?". La sessione "Building Proseware, a Non-Trivial Service Oriented System" è uno showcase di best practice che ogni sviluppatore (non solo .NET) dovrebbe sempre considerare. Oltretutto, e questo mi conforta non poco, molti hint citati da Clemens ricalcano fedelmente quanto spesso io stesso consiglio durante corsi, consulenze e conference. Tanto per citarne alcuni:

• I Web Service non dovrebbero mai contenere logica applicativa, ma essere soltanto dei gateway che ricevono la chiamata e la inoltrano al worker process effettivo
• Il worker process non dovrebbe _mai_ essere ospitato da ASP .NET, ad esempio per evitare problemi dovuti al riciclo della applicazione (o del pool)
• E' preferibile disaccoppiare il web service dal worker process, per esempio mediante l'uso di code
• Ogni servizio deve essere considerato autonomo: questo significa, per esempio, che non dovrebbe riportare all'esterno eventuali errori di sistema (database irraggiungibile, device indisponibile, ...) limitandosi a riportare eventuali fault applicativi
• L'effettiva tipologia della base dati (nonchè la sua struttura) dovrebbero essere totalmente incapsulate in layer appositi ed intercambiabili, magari selezionati a runtime mediante l'uso di opportune factory

Potrei continuare la lista (quasi) all'infinito, e non sarebbe mai abbastanza. Ciò che colpisce di Clemens è il pragmatismo, abbinato ad una assoluta padronanza della materia tecnica. Pochi fronzoli, e molte soluzioni concrete a problemi reali; spettacolare, divertente, critico e mai banale: in una parola... utile.