Complici una serie di motivi (a partire dalle prime chiacchiere sulla ipotetica/futuribile seconda edizione del
mattoncino), ultimamente ho introdotto un po' di codice "nuovo" in
NSK.
Per chi non lo conoscesse, NSK è il progetto open source che
Managed Designs ha avviato nel 2004 per poter disporre di una
reference implementation di architetture layered basate sul .NET stack: il lato positivo della vicenda è che una quota significativa della codebase e delle scelte di architettura/design proviene dai progetti "real world" che realizziamo in bottega, il lato negativo è che essendo un "toy project" al quale da un po' di tempo lavoro praticamente da solo gli update non sono frequenti quanto vorrei.
Tutto ciò premesso, ecco un
change log abbastanza fedele:
- La solution è ora VS2010/FX4 only: per chi desiderasse utilizzare la vecchia codebase ho predisposto una branch apposita
- Spazzata via la abstract factory "home made", ora lo stack è quasi tutto (e conto di rimuovere *ASAP* quel "quasi", ormai localizzato quasi solo nei progetti dedicati ad MVP) gestito mediante IoC.
- L'implementazione del DAL basata su "Unit of Work/Data Mapper" è stata rimpiazzata con un design basato sui repository. Per intenderci, significa che esiste una interfaccia IRepository<T> che estende sia ICollection sia IQueryable, quindi è "LINQ enabled". So che i "fan" del "Query Object by Managed Designs" non mi rivolgeranno la parola per mesi, ma è ormai chiaro che nel .NET space il qoery object idiomatico è LINQ, e quindi è inutile portarsi dietro quel "carrozzone legacy"
- Sempre parlando di Repository, ho implementato un repository generico basato su NHibernate 2.1 e, soprattutto, Linq 2 NHibernate. Questa implementazione è basata su una "sanitizzazione" di codice usato in produzione, quindi... funziona davvero, anche se non ho ancora "portato" in NSK tutti i test della codebase vera.
- Sempre in tema di NH: Il mapping è ancora basato sui file xml: come ho già avuto modo di discutere su Twitter, FluentNH (et similia) non mi hanno ancora conquistato, quindi... Xml <g>
- Ho *iniziato* ad implementare un repository basato su Entity Framework 4: il fine è quello di mostrare (alla facciazza di chi dice che non si può fare e quindi NH è un must "sempre-e-comunque") come effettuare un mapping "fluent/code only" di entità POCO. BTW, in ogni caso in scenari di questo tipo (code only, no designer, ...) IMVHO NHibernate rimane preferibile (e in fondo è il suo terreno “naturale”). Sottolineo quel IMVHO. BTW, avete notato che ho scritto IMVHO? <g>
- Il dominio è ora dotato di una modellazione qualitativamente molto superiore da un punto di vista DDD, ed anche la validazione basata sul VAB della EL può offrire interessanti spunti di riflessione
- Ho iniziato a "buttar giù" qualche diagramma UML/layer/architecture/blablabla in modo da permettere di dare una occhiata alle nuove feature di VS Ultimate/Premium
Considerazioni:
- La solution è ora molto più snella e, grazie anche a quale post build event, decisamente più facile da "eseguire" su una macchina "vergine" (in teoria, è sufficiente avere installato VS2010 e la Enterprise Library)
- La separazione delle reponsabilità tra i layer è ora decente, sorry per aver atteso così tanto nel "ripulire" #fail
- Buffo come io abbia iniziato ad utilizzare IoC container nel 2004 (addirittura parlandone in un workshop UGIdotNET) e l'abstract factory "casalinga" di NSK abbia resistito così a lungo. #fail
- I due punti precedenti mi fanno riflettere sulla lotta tra "codice che funziona non si cambia" e "la pigrizia non paga"
- Sono un dev, e nonostante tutti i miei sforzi per soffocare il mio "gusto estetico" mi rendo conto che, man mano che rifattorizzavo e miglioravo la codebase, aumentava la mia soddisfazione nel contribuire al progetto.
- La strada è ancora lunga, ma almeno il progetto l’ha intrapresa :-)