Dopo una lunga (e fastidiosa, almeno per il sottoscritto) assenza, torna un evento organizzato dallo “user group dedicato ai perché oltre che al come”; in una parola: GUISA. Il format è (crediamo) davvero innovativo: né sessioni “full frontal” né “open” né, soprattutto, tecnologia fine a se stessa bensì solo casi reali. Ogni sessione, infatti, presenta per 60 minuti un progetto “real world” del quale verranno mostrate le scelte architetturali e tecnologiche, motivando le suddette scelte; e dopo i 60 minuti… 30 minuti di “open” nel quale metterle in discussione. Insieme. Ma sempre partendo dai requisiti, perché vogliamo parlare e discutere...

Ultimamente, uno dei dischi del server UGIdotNET decide di dichiararsi “offline” ogni tanto. Poi riparte, ma il fenomeno è fastidioso (il volume deve essere ricostruito). Nessun reale problema per la “salute” dei nostri dati (blog, forum, news, …) perchè: il server dispone di una catena RAID6 (ergo, dovrebbero rompersi simultaneamente 2 dischi per essere faulty e “addirittura” 3 per perdere il volume) effettuiamo un backup “online” dei dati ogni 4 ore effettuiamo un backup offline dei dati (“qualche” Gb di database) 2 volte alla settimana ...

Con dei tempi decisamente troppo lunghi (mea culpa, e “millegrazie” a Daniele per la pazienza), da qualche giorno l’agenda dei Community Days è completa, con l’inserimento (grazie al supporto di GUISA) delle sessioni della track “Software architecture”. Riguardando l’agenda, mi sono reso conto che “spunta” un vero e proprio mini tutorial di Domain Driven Design imperniato su 3 sessioni: DATA01 - Build a LINQ-enabled Repository WEB01 - MVC++ ARCH02 - "Beyond" DDD: uno sguardo a CQRS and event sourcing La sessione di Alessandro è dedicata...

La domanda è di Aigor, ma poiché penso possa essere di comune interesse la pubblico anche qui. Da un paio di giorni, ho “committato” in NSK il DAL basato su Entity Framework 4. Utilizza (come da requisito) il Domain Model “vanilla” perché si avvale del mapping “POCO style” introdotto con la v4 dell’O/RM di casa Microsoft. Ho temporaneamente desistito dall’implementazione del mapping “Fluent” perché la CTP attuale del toolkit “Code Only” (che nel gergo MS significa “POCO & fluent” <g>) per EF è ancora troppo acerba, ma appena arriverà una nuova build (e AFAIK non dovrebbe mancare molto) riprenderò i...

Piccolo recap: A partire dal post di Giulio sul forum GUISA, il mapping fluent/POCO/code only con EF4 è la domanda che ultimamente ricevo più spesso. Un po’ per rispondere a tutti in “colpo unico”, un po’ perché la documentazione è effettivamente molto carente (in fondo si tratta di una feature in CTP3), ho iniziato a lavorare “seriamente” sul DAL EF4 di NSK: è ben lungi dall’essere finito, ma la “raffica” di check-in di ieri dovrebbe iniziare ad essere un significativo supporto per coloro che desiderassero intraprendere questa strada Con la definizione dei...

No, “Domain Model” non è un sinonimo “figoso” di “Object Model” e… No, non basta che il suddetto object model contenga classi chiamate “Customer”, “Product”, “Invoice”, etc etc per essere un Domain Model. Soprattutto se è anemico e sembra tanto una rappresentazione “your favourite programming language friendly” del database. Chiamo a testimoniare il paradigma Object Oriented :-)

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...

(Come al solito) In ritardo, ecco le slide della mia sessione “Architecting Web Applications” @ DotNetCampus; la demo è il “solito” NSK: la codebase online non è ancora aggiornata, ma cercherò di “committare” ASAP gli update. Colgo l’occasione per ringraziare e complimentarmi con lo staff per la splendida riuscita dell’evento: grande partecipazione di pubblico (quasi 500 presenti) ed addirittura un “passaggio televisivo” a TG3 Neapolis (per gli stomaci forti, al minuto 5:40 appaiono anche il sottoscritto ed il “portatile eretico”, a.k.a. “lo stronzetto” <g>). Un “grazie” particolare, infine, a RoB per la graaaaaaande pazienza che ha avuto con il...

Ricapitoliamo: BENE: la versione UML di riferimento è della famiglia 2.x BENE: permette di creare/associare work item TFS agli elementi presenti nei modelli. *Fantastico* MALE: non genera codice quindi il modello è messo lì solo per essere “ammirato”. Immaginate che divertimento (e che spreco di tempo) modellare (e mantenere in sync) 2 volte un “party pattern” (logical class diagram *e* EDM/Class Diagram). Ridicolo. “This feature is by design”? Grottesco. MALE: la modalità di configurazione degli elementi dei diagrammi è *totalmente* da rivedere: ad esempio, usare la propertygrid...

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...