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

Pensieri in libertà: Un (buon) compilatore produrrà "sempre" un codice maggiormente ottimizzato in confronto a quello prodotto da un essere umano, altrimenti io lavorerei ancora in assembly su workstation RISC. Un compilatore JIT ha la possibilità di produrre il codice migliore date le condizioni di runtime. Non sei d'accordo? No problem: smetti di usare .NET/il CLR <g> Preparati: Babbo Natale non esiste e un O/RM è (anche) un compilatore JIT di codice SQL. Ora fai un sospirone e rileggi i punti precedenti :-) Se il...

Con stupore, ho appreso oggi che il libro che ho scritto con Dino è risultato essere il più venduto al bookstore della PDC, più venduto dei libri dedicati ad argomenti "mainstream" quali Linq e Silverlight. Lo stupore è ancor maggiore se si pensa che il libro ha raggiunto come picco massimo la posizione 4140 nella classifica dei libri venduti di Amazon. Quattromilacentoquarantesimo, nella stessa categoria che contiene i best seller *veri*, quelli di Stephen King e Wilbur Smith, per intenderci. In una parola... WOW! "WOW" perchè la community degli sviluppatori "MS centrici", solitamente protezionista giacchè affezionatissima ai tool/fx di mammà,...

Se lo chiedono, come riferito dal mitico ughetto, anche il Cradle nonchè il Mostardone. Parliamone :-) Innanzitutto, leggete sia il post originale sia il thread dei commenti, che IMVHO è anche più interessante della domanda in oggetto <g> Ma torniamo a quel "cavolo" di SerializableAttribute: perchè essere costretti a decorare un oggetto in tal modo? A prima vista, in effetti è inutile: io voglio "solo" che EF/WCF/vattelapesca possa restituire col minimo sforzo un grafo e "minimo sforzo" significa "usa le mie classi as is e non chiedermi nulla di più". Insomma: parafrasando una famosa canzone eighties (Imagination) "Serialization, that's all I...

Negli ultimi mesi, complice anche la querelle "PI or not" portata alla luce da "vorrei ma non posso (ancora)" Entity Framework, ho ulteriormente riflettuto sul valore di un Domain Model agnostico alla persistenza ed ho concluso che PI non basta. Quello che "voglio" è un DM agnostico alla infrastruttura: non voglio PI, non mi basta. Voglio POCO, ma sembra che sia... Troppo <g> (interessante gioco di parole) Detta "seriamente", vorrei poter modellare un DM concentrandomi sulla soddisfazione dei requisiti "business" (DDD anyone?), ed avere uno stack tecnologico in grado di "appiccicare" in qualche modo il codice necessario alla infrastruttura....

Raffaeu mi porge un (gradito) complimento, che è però anche un interessante spunto per una riflessione. BTW, niente di nuovo all'orizzonte, perchè è una riflessione che ho già ampiamente esposto durante il tutorial dei Community Days, ma ritengo comunque interessante estenderla. Un moderno emulo di Gian Battista Vico non esiterebbe ad includere il seguente scenario tra i "corsi e ricorsi storici": quando un dev entra in contatto con i [design|architecture|refactoring|vattelapesca] pattern la reazione è, tipicamente, una delle seguenti: Il dev diventa un "pattern fanatic": parla continuamente di pattern e li infila dappertutto (un divertente "asse...

Ricapitoliamo: MS ammette pubblicamente che la PI è un punto fondamentale per un O/RM Per evitare di soffrire ulteriormente di problemi di eiaculazione precoce, MS ha allestito un focus group dedicato alla v2 di Entity Framework coinvolgendo *finalmente* gente esperta di queste tematiche: Eric Evans, Jimmy Nilsson, Martin Fowler, Pavel Hruby, ... Per supportare *seriamente* PI c'è bisogno di poter "proxare al volo" il DM Per "proxare" al volo senza eccessive penalizzazioni in performance serve Reflection.Emit Reflection.Emit è incapsulato egregiamente da...

Ok, sembra che il corso di settimana scorsa sia piaciuto e che, per l'ennesima volta, il tempo non sia stato sufficiente, giacchè Alessio avrebbe gradito un approfondimento sul tema "Query Object". Provo a "rimediare" :-) In realtà la richiesta di Alessio sottointende 3 distinte tematiche: "Query Object": chi era costui? Implementazione "hand made" di un DAL capace di gestire in maniera sensata la persistenza di un DM Produzione "al volo" del codice SQL Andiamo in ordine: il design pattern query object è una specializzazione...

Venerdi io e il socio ci siamo avventurati in una delle nostre chat "tenniche". Man mano che proseguivamo ho pensato che, malgrado le imprecisioni e le "approssimazioni" tipiche della "presa diretta", tutto sommato quanto stavamo scrivendo costituisse un interessante "bigino" architetturale e abbiamo deciso di pubblicarla.
(Clicka qui per leggere)

Questo post (dedicato a LINQ to SQL) di Corrado è un buon punto di partenza per una riflessione dedicata ad una delle caratteristiche salienti (e spesso poco comprese) di ogni strumento O/RM, ossia l'Identity Map. (continua)

Oggi, chiacchierando con Mauro durante una riunione di stato avanzamento lavori in bottega, ci siamo soffermati su un suo post sul forum UGIdotNET, in risposta a Raf. Il thread è interessante (nonchè breve :-) ) e merita una lettura; per i più pigri, ecco lo stralcio oggetto della nostra chiacchierata: (continua...)

Ho approfittato di alcuni viaggi in treno effettuati negli ultimi giorni per estendere l'implementazione di Model View Presenter in NSK. Nulla di trascendentale, ma le nuove view sono basate su un subset ("sanitizzato", come direbbero i Microsoft guys) del mini-framework MVP che io e Markino abbiamo implementato per i progetti che realizziamo in Managed Designs. In pratica, oltre alle "solite" interfacce che definiscono i contratti caratteristici di view e presenter, offre alcune implementaziono concrete e generiche utilizzabili come scorciatoia. Technorati Tags: Managed Designs, model view presenter, NSK, northwind starter kit, software architecture

Matteo è dubbioso, e Janky lo rassicura: LayerSupertype, evitandone gli abusi, non è Male. Concordo: concentrare il "plumbing" del nostro DomainModel in un layer supertype per poter creare contesti polimorfici è Bene (ed infatti è una delle design guidelines attuate in Managed Designs, a partire da NSK). Bruciarsi la classe base delle entità perchè un tool (O/RM anyone?) non è "zero friction" e lo richiede è Male. Applicare un pattern perchè "ipse dixit" è Male; riscontrare che ci troviamo nello scenario affrontato da un pattern ed utilizzarlo (il pattern) per evitare di reinventare la ruota è Bene. Cum grano salis, insomma. Technorati Tags: domain model, layer supertype, design pattern, software architecture, NSK, Managed Designs

Persistence Ignorance: OK, I think I get it now. (cit.) Preferirei essere io l'autore di questa frase. Forse anche Janky (che me la ha segnalata e, a differenza del sottoscritto, sta contanto fino a 10-mila- prima di postare al riguardo) lo preferirebbe. Ma l'autore è uno dei membri del team di Entity Framework, e il post è del 2 giugno. *2007*. Che "ObjectSpaces, atto III" non brillasse già lo sospettavo (vedi il punto 2: "potrò definire *liberamente* il mio Domain Model"), ma adesso sappiamo che -nonostante il delay nel rilascio- la versione 1 non sarà in grado di gestire entità "persistence ignorant" perchè......

”Stephenson spiega chiaramente agli studenti la sua visione del mestiere quando insiste sulla passione «design is subjective, passion does it». Ai giovani designer raccomanda anche di non perdere mai la capacità di disegnare perché se il computer aiuta, è lo sketch il linguaggio base per comunicare il progetto. E il buon design «can be described in a few lines».” La fonte è VirtualCar e Frank Stevenson è un -noto- designer di auto (sua è la firma di progetti quali Mini e X5 di BMW), ma la (forte) sensazione è che quello citato sia un buon consiglio anche per "altre" categorie di...

Questo post di Marco si conclude così: LINQ to SQL vs. LINQ to Entities - potremmo ragionare per ore e per giorni su quale sia il giusto posizionamento dei due. Lo faremo sui blog dedicati. Ma la vera verità è che tra i due c'è qualche sovrapposizione. Nel lungo periodo saranno unificati (detto da persone Microsoft). Quanto sia lungo questo periodo e cosa comporti l'unificazione, questo è tutto da decidere. Considerazioni non tecniche: LINQ to SQL esce prima, LINQ to Entities è più ambizioso ma esce qualche mese dopo. In termini di ridistribuibili e di adozione di massa, questo avrà un...

ObjectSpaces posticipato. WinFS posticipato perchè avrebbe dovuto basarsi proprio su ObjectSpaces. ObjectSpaces tagliato. WinFS tagliato. PDC 2005, ed ecco quell'obbrobrio chiamato DLINQ. E mazzate, tante mazzate a MS: da tutti, da subito. Bouma, Ayende, anche (nel proprio piccolo) dal sottoscritto. Semplicemente, alcuni pazzi furiosi (siculo incluso, ovviamente) si sono resi conto che un ORM *vero* "si può fare!" (cit.) La risposta di MS fu "Entity Framework", tra le cui sfavillanti caratteristiche possiamo sicuramente includere: layer supertype imposto, SQL Server only, ... Ed ecco il colpo di scena: forse hanno capito che tirar fuori l'ennesima opera incompiuta non avrebbe avuto molto senso. Ecco...

A tutt'oggi, considero TypeMock il miglior tool disponibile per creare mock objects, per la sua capacità di "mockare tutto": virtuale o meno, statico o meno... Per lui non è un problema. Ecco perchè non ho ancora attraversato il fiume adottando RhinoMocks, che produce mock oggettivamente migliori (leggi: "type safe") ma è decisamente più schizzinoso in merito ai membri effettivamente "mockabili".Personalmente, credo ogni tool(kit) dovrebbe essere "zero friction" (ed è qui, per esempio, *IMVHO* LINQ perde nei confronti di Hibernate a causa del mancato supporto alle entità PI), ma questo commento esprime una opinione diametralmente opposta. Dovremmo quindi rendere tutto virtual (alla Java, per intenderci) e rinunciare...

L'ho combinata grossa: la telefonata mattutina col socio si è trasformata in un post che avrei voluto scrivere da mesi, senza riuscire mai a trovare tempo (e voglia). (Clicka per leggere)

Dopo Omid e Lorenzo, lunedi prossimo toccherà a me concludere presso l'università di Trento il mini tour co-organizzato da GUISA e Microsoft Italia. Innanzitutto, parliamo di cose serie: poichè io sarò a Trento per tutta la settimana, potremmo organizzare una cena post-evento. Gli interessati facciano un fischio. <g> Largo, ora, alle... Amenità: sto introducendo qualche modifica alle slide perchè la settimana trascorsa a Redmond mi permette di introdurre (NDA vari permettendo) qualche considerazione "futurista" inerente le tematiche: data mapping, testing e presentation layer (soprattutto lato web). In ogni caso, l'agenda rimarrà molto pragmatica ed orientata alle soluzioni/scelte operabili *oggi*, motivo per il quale includerò...

Con i 2 episodi di oggi si conclude la seconda serie di webcast per "aspiranti" architetti che GUISA ha organizzato in collaborazione con Microsoft Italia. Ne avevo già parlato, ma poichè ho (appena) finito le slide posso finalmente essere più preciso. Credo che il titolo del primo ("SO != OO"), che si svolgerà alle 11:00 ed al quale è possibile iscriversi qui, sia decisamente esplicativo: cercherò infatti privare di fondamento il diffusissimo luogo comune secondo il quale SOAP sia "RPC over HTTP" e permetta di distribuire oggetti. Il secondo, intitolato "soluzioni del mondo reale", inizierà alle 14:30 ed avrà una durata "indefinita" (va beh,...

Lorenzo mi ha ricordato che sul numero di PC Professionale attualmente in edicola è stata pubblicata la registrazione della sessione ".NET Architectures in the Real World" che ho erogato durante WPC. Durante la sessione mostro l'architettura (e l'implementazione) di due progetti dei quali sono stato architetto e che considero interessanti perchè sfatano un paio di luoghi comuni. Uno dei due progetti è l'ormai famigerato GazzaTown, ossia l'e-commerce della Gazzetta dello Sport che ho progettato per conto di Fattore K. In un mondo che (fondamentalmente) pensa che l'architetto sia "quello che conosce i pattern e disegna i diagrammi", questo progetto mostra l'importanza...

Discussioni come questa sono un classico, e classica è la domanda: "devo definire i miei tipi base sotto forma di interfaccia o classe?" Il principio di design "program to an interface, not an implementation" [GoF, 18] sembrerebbe consigliare la prima ipotesi, apparentemente in contrasto con Cwalina che, nelle Design Guidelines, afferma: "Do prefer classes over interfaces". Chi ha ragione, quindi? (continua)

Ecco, finalmente, i video degli Architecture Days :-)

Update interessante per NSK, che integra quanto anticipato: Ho completato il query model (sostanzialmente una implementazione di Query Object), che ora permette di esprimere le clausole di ordinamento dei risultati Ho corretto il bug del DAL basato su Hibernate: sostanzialmente, il QueryTranslator in alcuni contesti faceva cilecca (lo so che sono un pollo: prima di correggere il bug, avrei dovuto scrivere un test che lo scatena) La Unit of Work ora è "disposable by design" (work item chiuso) Ho integrato una rudimentale (leggi: schifosa) implementazione di identity map....

...And it sounds like a whisper (cit.) Revolution è il codename della nuova versione del sito UGIdotNET, (in parte) pre-pre-pre-visionabile qui: http://vnext.ugidotnet.org. Perchè "Revolution"? Perchè è riscritto "from scratch", da zero. Tempo addietro provai a portare la codebase attuale verso la v2 del framework, ma ad un certo punto capii che sarei riuscito "solo" ad introdurre alcune feature del nuovo framework, senza goderne davvero dei benefici. Ed allora... Revolution. Revolution perchè oggi posso "barare" e partire nello sviluppo da basi differenti rispetto a quelle a mia disposizione nel lontano 2001, quando realizzai il "core" della codebase che, in un modo o nell'altro,...

...Saranno pubblicate sul sito GUISA, nella sezione "Download" (gruppo Webcast/Aspire Architect 2006). Al momento, ho pubblicato quelle del webcast di lunedi scorso. Technorati tags: software architecture, GUISA, webcast

Durante una delle mie sessioni erogate in occasione degli "Architecture Days" ho citato il toolkit CastleProject.ActiveRecord che, fondamentalmente, incapsula NHibernate per permettere di implementare in maniera molto agevole il pattern ActiveRecord. In tale occasione, ho affermato che il progetto "Generator" (ossia il tool in grado di derivare le entità dal database sotto forma di classi) è dichiarato sospeso (nella nuova versione del sito CastleProject la pagina ed esso dedicata è addirittura stata rimossa). Diego Guidi, invece, mi riporta che l'autore del suddetto tool sta proseguendo indipendentemente il suo sviluppo anche se l'unico modo per ottenerne una copia funzionante, al momento, richiede di scaricare e compilare autonomamente...

Pian piano (ok, lo ammetto: con imperdonabile ritardo) anche l'agenda WPC emerge: ecco i tutorial. A breve l'abstract completo e i primi titoli delle sessioni. Non sparate sui pianisti :-)

Ingolosito dal post di Janky, ho installato la CTP dell'entity designer per ADO vNEXT (o LINQ, se preferite); sembra che a Redmond abbiano le idee chiare: gli sviluppatori .NET non hanno bisogno di un ORM e l'ereditarietà a livello di Domain Model non serve a una mazza, quindi si può "bruciare" con il loro layer supertype. Ineccepibile, anzichenò! <g>

Non ci posso credere: ho pubblicato con quasi un mese di anticipo gli abstract delle mie sessioni del workshop... Vado subito a provarmi la febbre <g> Technorati tags: UGIdotNET, GUISA

I blog sono una risorsa fantastica, peccato siano così dispersivi: quando il numero di sottoscrizioni inizia ad essere "importante", ti ritrovi a leggere i post velecemente e (ahimè) superficialmente. Certo, la mia abitudine di ignorare i commenti ai post mi fa risparmiare un po' di tempo, ma evidentemente non abbastanza (in fondo, vorrei *anche" lavorare ed avere una vita privata <g>). Fortunatamente, "a volte ritornano" (cit.) e quindi stamattina ho riletto questo post di Martin Fowler, che offre un interessante punto di vista sulla implementaziona di interfacce implicite (che è tutt'altra cosa rispetto alla "implementazione implicita di interfaccia"). Come Martin spiega,...

Forse ha ragione David: la mia risposta al post di Giulio (per quanto sintetica e quindi non esaustiva) non è proprio da buttar via. Per dovere di cronaca, la riporto qui. (Clicka per leggere)

Forse non tutti se ne saranno (ancora) accorti, ma il focus di Microsoft Italia in merito alle tematiche di design architetturale è in deciso aumento, e ciò non può che rendermi felice. E' quindi con immenso piacere che, a luglio, ho accolto la proposta di Giuseppe e Sara relativa alla preparazione di una serie di webcast architetturali "griffati" Managed Designs. (Clicka per leggere)

Leggo con piacere dal blog di Stefano che Pablo Castro ha nuovamente confermato (già lo si sapeva), che LINQ (o come lo vogliamo chiamare) non farà parte del FX 3.0; speriamo che il tempo a disposizione del product team permetta loro di recepire il concetto di domain model... <g>

Interessante post tratto dal blog di Bill Simser: se ci trovassimo su Usenet, direi "quoto tutto" <g> Technorati tags: software architecture

Non si può proprio mai stare tranquilli: Martin Fowler ha annunciato sul proprio bliki di aver "ritirato" il pattern Model View Presenter dalla lista dei pattern candidati all'ipotetico secondo volume della serie P of EAA. Le caratteristiche di MVP sono ora state ripartite nei pattern Supervising Controller e Passive View. E' interessante notare che Martin si dichiara indeciso se eliminare del tutto l'uso della parola "Controller", utilizzando quindi Supervising Presenter quale nome per il nuovo pattern. Beh, se non altro non ho ancora pubblicato l'agenda del workshop "Architecture Days"... <g> Technorati tags: software architecture

Ok, lo ammetto: mi ero illuso. Pensavo che la Forza avesse fatto il suo corso, sconfitto il Lato Oscuro e che avremmo avuto un ORM incluso nel framework. Pensavo che il significato di "definire il *mio* domain model e realizzarne il mapping verso uno store relazionale in modo non invasivo" fosse abbastanza chiaro. Lette le specifiche, non riesco a pensare che un tool che genera il domain model a partire dallo schema relazionale sia una buona soluzione. Nemmeno se il mapping è estraneo al domain model. E... No, il fatto che le classi siano generate come "parziali" non mitiga affatto...

Le specifiche esordiscono con: While the relational model has been extremely effective in the last few decades, it’s a model that targets a level of abstraction that is often not appropriate for modeling most business applications created using modern development environments. Ed ecco già 10 minuti di standing ovation di "Fantozziana" memoria ("La corazzata Potemkin, è una ****** pazzesca!..." [cit]). Ora ditemi che: butteranno quell'ignobile meccanismo di tagging del domain model potrò definire liberamente il *mio* domain model (opzionale, ma non troppo) avrò un tool *decente* per produrre il file xml di mapping espresso a pagina 31 non sarò obbligato a "ricompilare" per cambiare il mapping E il 5 per mille lo...

Ho cambiato idea: la prima GUI *architetturalmente* decente disponibile per il Northwind Starter Kit sarà web e basata su Model View Controller, quindi nisba (per il momento) Model View Presenter. Non solo: l'implementazione MVC sarà molto semplice, e non utilizzerà toolkit esterni; il motivo è semplice: uso NSK come applicazione reference per i miei corsi ed eventi/webcast, ed alla domanda "Che libri consigli per studiare le tematiche relative al design?" rispondo sempre "Almeno GoF e P of EAA". Spesso, inoltre, questi testi sono già posseduti dai partecipanti. Ebbene, in [P of EAA] Martin presenta una semplice implementazione ASP.NET di MVC, fondamentalmente...

Chiunque abbia scaricato il famigerato Northwind Starter Kit si sarà accorto che, mentre i layer business e data sono già strutturati in modo abbastanza adeguato, lo stesso non si può affermare per la parte GUI. Ciò è avvenuto per motivi "storici" che potrei spiegare in separata sede (un altro post ?), se qualcuno fosse interessato al "dietro le quinte" di questo progetto. Rimanendo in tema, però, rimane la "questione GUI": ho quindi deciso di focalizzarmi, in questo periodo, sullo sviluppo di questa parte di progetto. Mi piacerebbe, ad esempio, che NSK disponesse di GUI multiple, implementate con strategie differenti: per esempio,...

Per il quinto anno, avrò l'opportunità di contribuire ad abbassare il valore di WPC: quest'anno proverò a combinare danni sproloquiando in tema di object oriented design. Ecco, nel dettaglio, l'abstract delle mie sessioni. Si accettano suggerimenti :-) Real world OOD: il business tier [SVI224]Dalle Model-driven Architectures [OMG] alla pratica del Domain Driven Design (D3): il fondamento di un moderno sistema enterprise consiste nel disegno di un Domain Model che esprima le business entity gestite dal sistema, procedendo quindi con la modellazione della business logic che implementi i servizi applicativi. In questa sessione introdurremo i principi di un business layer, adottando pattern...

Grazie a questo post di Lorenzo vengo a sapere che Ward Cunningham, che ho avuto il piacere di incontrare e conoscere 2 settimane addietro presso il summit MVP, lascia Microsoft per diventare il decimo impiegato di Eclipse. E' una perdita grave, ma ancora più grave è IMVHO il fatto che *penso* di poterlo capire e giustificare. Hai nella tua squadra Ward e lo mortifichi nel team delle PAG, quando il suo apporto sarebbe stato manna del cielo nel team di TFS (tanto per fare un esempio). Hai in squadra James Newkirk, e gli "appioppi" lo stesso destino. E fai "uscire"...

Mr Roberto Faiga a parte (a proposito: tornerà in Italia o rimarrà qui?), il vero tormentone qui a L.A. ha un nome ben preciso: LINQ. Oltre ai suoi "gusti" dLINQ e xLINQ, ovviamente. Dopo una notte di riflessioni e confronti con i miei compagni di viaggio, ho assistito alla sessione di Luca Bolognese, della cui disponibilità ho approfittato per torgliermi alcuni dubbi mediante qualche domanda mirata e forse anche un po' cattivella. Innanzitutto, i miei complimenti a Luca, perchè la sua sessione è stata divertente e ben bilanciata. Lo ringrazio anche per la sincerità con la quale dal palco ha...

Nel mare di feedback trionfali, una voce fuori campo: a me dLinq *non* sembra una soluzione ragionevole. dLinq accoppia il Domain Model allo schema fisico dei dati, e questo è Male. Secondo "lui", una classe==Una tabella. Una proprietà==Una colonna. Il tipo della colonna *è* il tipo della proprietà, e anche questo è Male. Il mondo reale non funziona così. Un esempio? Database Northwind (lo abbiamo tutti), tabella Employees, colonna ReportsTo. E' di tipo int, è nullable e, dove specificato, indica il codice dell'impiegato che ci coordina. In un domain model "Real World", la classe Employee *non* ha una proprietà ReportsTo di...

Avete presente quando venite assaliti da un dubbio e (quasi) non riuscite a pensare ad altro? Ecco: immaginate che il dubbio riguardi una funzionalità di .NET e che MSDN non sia esaustivo al riguardo, immaginate che anche Raf (cui ho rotto le @@ via messenger) non vi sappia dare una risposta al volo... Concorderete con me che è uno di quei casi nei quali ci si sente *obbligati* a "mettere in piedi" un esempietto per: vedere, capire, ....SAPERE. Vaorainonda, il reality show: "Vita da Saltarello: riflessioni sugli attributi" (si, il doppio senso ambiguo carpiato è voluto ). La causa scatenante di cotanto...

Oggi alle 14:30 erogherò per Microsoft il primo dei 3 webcast dei quali avevo già parlato qualche tempo addietro; in realtà, da allora qualcosa è cambiato: ho pensato di riformulare i titoli e più in generale l'agenda degli argomenti, a mio avviso ora più lineare. Non nascondo che il feedback ricevuto per il workshop UGIdotNET "Architecture and Management" mi sia stato di grande aiuto per "tarare" anche questi webcast: ennesima occasione per ringraziare chiunque mi abbia regalato il proprio punto di vista (oltre che per ribadire che slide e demo sono in pubblicazione... anche il codice, datemi solo un po'...

Spesso (è successo anche a WPC) mi viene chiesto quale sia l'impatto dell'uso sistematico del Refactoring o della implementazione di test unitari all'interno di un processo di sviluppo. La risposta breve è davvero tale (ossia... Breve): tipicamente infatti "spedisco" qui il richiedente. La generalizzazione (ovviamente non nel senso OO del termine) è però un processo pericoloso: l'ottimo post di Marco rischia infatti di generare nei meno esperti l'errata convinzione che il tempo necessario al refactoring sia "annegabile" poichè composto da tanti piccoli "passi" individualmente sempre poco onerosi. Non so voi, ma per quanto mi riguarda alcuni pattern di refactoring sono tutt'altro...