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 qualche impatto. Comunque la storia è ancora tutta da scrivere e vi assicuro che non avevo ancora visto un tale livello di competizione tra due team (abbiamo parlato con persone di entrambi...) all'interno di una stessa azienda. L'idea che mi sono fatto è che il problema esiste soprattutto in prospettiva: cosa potrebbe fare una versione 3 dei due prodotti che non possa essere fatta anche dall'altra?
Spostandoci dal dominio della tecnologia a quello dell'architettura, è evidente che ci troviamo di fronte all'ennesimo capitolo della saga "Active Record (LINQ to SQL) vs. Domain Model" (LINQ to Entities): entrambi i pattern "mappano" un object model su una struttura relazionale e in entrambi i casi l'object model contiene "both data and behaviour", ma è l'approccio ad essere differente, perchè differente è il lo scenario che questi pattern di modellazione della domain logic vogliono affrontare. Active Record evolve Row Data Gateway, aggiungendovi la logica di dominio (...The principal difference is that a Row Data Gateway contains only database access while an Active Record contains both data source and domain logic. - [P of EAA, 161]) ma rimane fondamentalmente un object model influenzato dalla struttura del database. Domain Model, invece, è "requisite driven" ed è quindi definito considerando esclusivamente l'analisi (ad eccezione delle tipiche -e, si spera, rare- "spurie" introdotte per ragioni "tennologgiche"). In soldoni, Active Record è il miglior object model ottenibile partendo dal db, tipicamente in collaborazione con un toolkit che implementa la persistenza, mentre Domain Model è l'object model che emerge guardando pressochè esclusivamente ai requisiti funzionali. Come si lega tutto ciò alla domanda di Marco? E' semplice: pensandoci bene, il mapping caratteristico di Active Record è un caso particolare di quello di Domain Model ed infatti l'altra metà del cielo usa NHibernate come engine di persistenza in entrambi i casi, eventualmente abbinato a CastleProject proprio per i mapping "db driven". Le sovrapposizioni tra i 2 gusti di LINQ sono quindi talmente normali che... Semplicemente non dovrebbero esserci, perchè entrambi potrebbero utilizzare il medesimo engine, facendo emergere mapping e tool differenti e dedicati ai rispettivi scenari di adozione.
[Non so perchè, ma ho la sensazione che le sessioni dei Community Days dedicate a LINQ saranno caratterizzate da Q&A alquanto "animati"...]
Technorati tags: linq, active record, domain model, nhibernate, castle project, design pattern