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 tipo (nullable?) int, bensì una proprietà Manager di tipo Employee. E vi dirò di più: la proprietà assumerà il valore dello special case MissingEmployee (uno special case, insomma), ove non esista un manager associato all'impiegato. E si potrebbe continuare... Ma finiremmo per avere nostalgia di NHibernate o anche solo delle alpha di ObjectSpaces. Intendiamoci: Linq *è* una figata. Per quanto sia solo "compiler magic", basato sugli extension methods e gli anonymous types di C# 3.0, l'effetto funzionale è notevole. xLinq mi sembra assolutamente ragionevole. dLinq, invece... "non è". Per uno sviluppatore, dLinq apparirà probabilmente come una Terra Promessa, ma chiedetemi un parere da architetto, e la mia opinione sarà: "Occasione mancata". Questione di punti di vista.
posted @ giovedì 15 settembre 2005 19.18