Preparando il materiale per il tutorial “.NET Solution Architecture” che erogherò presso BASTA! Italia on Tour, ho optato per una agenda alternativa a quelle tipicamente dedicate a questa tematica: l’idea sarà quindi quella di partire dal “metodo” e non dalla “soluzione”; Domain Model, MVC, O/RM, SOA, etc etc sono tutte “belle cose", ma… Ne abbiamo *davvero* *sempre* bisogno? Ha sempre senso definire una architettura layered? E i tier? E la tennologggia?
I pattern (a qualunque livello di dettaglio o in qualunque dominio: architetturali, design, refactoring, test, …) nascono come “…soluzioni sperimentate a problemi ricorrenti…” dove i “problemi” sono i “requisiti” e non oggetti a sè, da usarsi e rimirarsi per nostro compiacimento estetico e pensare di aver predisposto una soluzione “cool”. La tecnologia è uno strumento: EF, NH, WCF, … si adottano se e quando abbassano il costo di implementazione/gestione dell’artefatto, e non per essere a la page in rapporto al guru/vendor di turno. E’ una piccola “battaglia” che ho iniziato in occasione degli Architecture Days 2006 nella famigerata sessione “Life between…”: chi c’era si ricorderà un lungo elenco di “ipotesi risolutive” (es: TS, TM, AR, DM, SL, SOA, …). Senza un problema, insomma, non c’è una soluzione: la soluzione esiste in funzione del problema, e non come ente a sè.
Tutorial “fuffoso” trascorso a parlare di “aria fritta”, quindi? Nemmeno per sogno, visto che –a puro titolo di esempio- parleremo di:
- Come usare Entity Framework per gestire un Domain Model, ma solo dopo aver parlato di cosa sia *davvero* un Domain Model e di quando abbia senso implementarne uno: sono “entità” anche quelle del modello Chen, non c’è sempre bisogno di aggrapparci ad Evans
- Entity Framework/NHibernate, ma solo dopo aver definito cosa sia un O/RM al fine di utilizzarlo essendo consapevoli della sua natura e non imparando a memoria l’elenco delle feature
- Come usare WCF per implementare servizi SOAP/queued/transazionali/blahblahblah, ma solo dopo aver dato una definizione *contestualizzata* di servizio (tanto per fare un esempio, “servizio” in SOA e DDD hanno due significati non completamente sovrapponibili)
- Virtualizzazione, per capire se e come “roba” tipo ESX o Hyper-V possa risultare vantaggiosa dal punto di vista architetturale e quali requisiti non funzionali possa soddisfare o, addirittura, introdurre
- Inversion of Control, per capire come trarne davvero vantaggio e non finire a fare il solito esempietto basato sul container che istanzia l’implementazione concreta di ICustomer (ma in che film l’implementazione della domain logic ha bisogno di essere sostituita?)
- ASP.NET MVC, per vederlo all’azione in un progetto reale (dove Assert.IsTrue(“reale”==”funzionante in produzione”) <g>)
Come al solito… “Io speriamo che me la cavo” (cit.)
UPDATE: dimenticavo: gli organizzatori hanno offerto uno sconto sulla quota di iscrizione ai soci UGIdotNET
posted @ martedì 28 aprile 2009 11.33