Qualche settimana fa ci siamo ritrovati io e il pres a giocare a ping pong. Serata molto piacevole perchè tra uno scambio e l'altro si chiacchiera un po di .net e dintorni.
Ricordo ancora la penultima volta in cui avevamo impugnato le racchette (quasi un anno e mezzo fa). L'argomento preferenziale era ORM e NHibernate, ed era un periodo in cui per ogni discussione nascevano flame da tutte le parti. Adesso anche per l'avvento e l'adozione di ORM in casa Microsoft, se ripenso a quelle "battute" mi sembra di rivederci come dei visionari...che però qualche cosa l'avevano azzeccata.
L'argomento di questa volta, era un po di AOP. L'ho sollevato io perchè ho un bel modulo nel corso di architetture enterprise che sto preparando, che riguarda l'isolamento transazionale e le capacità di testing degli applicativi da affrontare in logica AOP con evidenti vantaggi architetturali.
L'AOP è un modo complementare all'OOP di risolvere alcuni problemi che per costruzione danno fastidio all'Object Orientation e specificatamente al principio di Incapsulamento. Ci sono infatti alcuni aspetti di programmazione che per loro natura sono dispersi in molte classi invece di essere localizzati in punti ben precisi. L'AOP permette di modularizzare questi aspetti (chiamati CrossCutting Concern) ed evitare la dispersione nel nostro codice.
Ne vorrei elencare qualcuno:
Authorization: il codice che decide "chi" può eseguire "cosa".
Logging: il codice che traccia le operazioni in vari canali di scrittura
Transaction: il codice che determina l'isolamento transazionale di un processo di business. Chi decide l'isolamento? Chi mette il veto?
E qui la giusta battuta di Andrea: "ecco! i detrattori del'AOP ti diranno che gli argomenti sono sempre gli stessi...".
E infatti gli esempi di AOP che si trovano in giro molte volte sono scadenti.
Andando un po in profondità allora aggiungo:
Retry: la logica di controllo di quanto e come effettuare una connessione in presenza di errori di rete.
Caching: logica di gestione di memorie buffer di qualsiasi tipo replicate o distribuite su più nodi di cache.
Expection Handling: logica di gestione delle eccezioni, eventuale trasmissione e wrapping delle exception tra i vari layer applicativi.
Localization: la localizzazione dei field di un oggetto di dominio, può essere considerata trasversale a tutte le entity e anche al sistema di persistenza stesso.
Session Handling (o PersistenceContext handling): logica di gestione dei contesti di persistenza, apertura chiusura e ciclo di vita. Chi lavora con NH e presto lavorerà con Linq to SQL o EF, presto ne avrà a che fare
E mi fermo perchè ce ne sarebbero tanti altri.
Adesso ad una prima vista uno potrebbe dire...mmm ok...ma sono tutti aspetti infrastrutturali, o non funzionali...quindi l'AOP non si applica solo a questi? Non è così.
L'AOP è applicabile ad aspetti funzionali se si capisce bene la differenza tra un Requisito e un Concern, ed è possibile fare analisi/design vero e proprio modellando gli Aspetti negli Use Case e con UML.
Consiglio a chi fosse interessato all'argomento la lettura di questo testo:
PS:
Doveroso dire che questi sono gli argomenti del riscaldamento, pre-partita, perchè quando iniziamo a giocare poi....
siamo troppo concentrati a prendere il "net più bastardo" o "l'angolino più maledetto"!!