Tutorial “.NET Solution Architecture”: riflessioni

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 @ Tuesday, April 28, 2009 11:33 AM

Print

Comments on this entry:

# re: Tutorial “.NET Solution Architecture”: riflessioni

Left by Adrian Florea at 4/28/2009 5:22 PM
Gravatar
ho letto a voce alta, in rumeno, questo post, qui ai miei ragazzi troppo innamorati della "tennologggia"...

grazie Andrea!

# re: Tutorial “.NET Solution Architecture”: riflessioni

Left by Giulio at 4/29/2009 2:22 PM
Gravatar
Cacchio... l'agenda mi sembra più interessante. Peccato non poterci essere :-(

Comunque, indipendentemente dalla mia augusta presenza: in bocca al lupo! :-)
Comments have been closed on this topic.
«September»
SunMonTueWedThuFriSat
25262728293031
1234567
891011121314
15161718192021
22232425262728
293012345