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