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 @ martedì 28 aprile 2009 14:33

Print

Comments on this entry:

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

Left by Adrian Florea at 28/04/2009 20:22
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 29/04/2009 17:22
Gravatar
Cacchio... l'agenda mi sembra più interessante. Peccato non poterci essere :-(

Comunque, indipendentemente dalla mia augusta presenza: in bocca al lupo! :-)

Your comment:



 (will not be displayed)


 
 
 
Please add 7 and 1 and type the answer here:
 

Live Comment Preview:

 
«ottobre»
domlunmarmergiovensab
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789