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

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

Technorati Tag: design pattern,comics

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

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

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