Linq

Linq to SQL NON è un Active Record...

Giancarlo Sudano — Mon, 26 Nov 2007 14:21:49 GMT

Negli ultimi giorni chissà quante volte l'ho letto, mo' mi sono stancato...:-)

Ripeto:
Linq to SQL non è un Active Record.
Linq to SQL è un ORM puro.

da Fowler:
"An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database"

E ora veniamo a noi, ecco qualche concetto takeaway da memorizzare e studiare a casa:

1. L'Active Record definisce che la responsabilità del ciclo di vita di una entity è sulla entity stessa. In Linq to SQL la responsabilità è delegata al DataContext (come in un qualsiasi ORM che si rispetti). Nella implementazione di Caste.ActiveRecord infatti, tutte le entity derivano da una base comune che ha i metodi .Save(), .Insert(), etc. etc.

2. L'Active Record prevede che la struttura della classe che rappresenta la entity sia più o meno simile alla struttura del record sul db (e da dove verrebbe il nome allora?). In Linq to SQL ci si può scostare enormemente, riusciendo a mappare tranquillamente la many-to-one e il l'ereditarietà (non è possibile avere per adesso Composizioni di oggetti mappati, aka Component per i NHibernettiani)

3. Linq to SQL ha un wizard che parte dalla struttura del DB. Questo non lo fa di certo un Active Record. Al massimo si può dire che il wizard è (giusto un po...:-)) datacentrico. Ma (come ho già dimostrato ampiamente ai community days) con Linq to SQL si può partire dalla classe entity e mappare o con attributi o con file XML.

Quindi:
mancanza di mapping 1 a 1 con la tabella...
responsabilità delle CRUD operation non sulla entity, bensì sul contesto di persistenza....
stop così.

ps: Se poi da li passasse il buon Raf, vi direbbe che Linq to SQL è uno strumento per costruire DAL...
Ok Raf non siamo in disaccordo...ogni ORM serve a scrivere i DAL....va bene così? :-)

Confronto: NHibernate - Linq 2 SQL - Entity Framework

Giancarlo Sudano — Mon, 27 Aug 2007 23:35:51 GMT

Mi è stato chiesto molte volte, anche su Guisa esiste un bel thread sul confronto di questi tre ORM, quindi ne ho approfittato per fare una matrice che incrocia le feature di questi tre prodotti. Ahime non ho ancora qualche informazione su Entity Framework e consideranto che quest'ultimo è ancora in CTP,la sua colonna potrebbe essere passibile di modifiche.
Ho usato il simbolo "??" nelle feature di cui non ho ancora conoscenza.
Siete invitati a propormi qualche eventuale feature su sui trovare i confronti, terrò aggiornata la tabella.

	NHibernate	Linq to SQL	Entity Framework
Mapping con Attributi	Si	Si	Si
Mapping con XML	Si	Si	Si
Persistenza Trasparente	Si	Parziale. Per la gestione delle collezioni e dei proxy bisogna usare dei tipi specifici	Parziale allo stato attuale. Le entity devono implementare una interfaccia
Persistenza Transitiva	Si	No	No
Strategie di Fetching	Si	Si	Si
Strategie di Ereditarietà	Tutte le strategie	Solo la Table per Hierarchy	Tutte le strategie
Mapping Entity su più tabelle	Previsto il porting da Hib 3.2	No	Si
Mapping di Value Type	Si	No	Si
Linguaggio di interrogazione a oggetti	HQL (stringhe)	Linq applicato a DataContext	Linq to Entities (applicato a ObjectContext) per c# e vb.net. eSQL (stringhe) per tutti i linguaggi.
Lazy load	Si	Si	Si
Mapping di chiavi composite	Si	Si	Si
Multi-database vendor	Si	No	Si
Tracking stato entity	Contesto di Persistenza.	Contesto di Persistenza o Entity	??
Identity Map	Si	Si	Si
Caching di entity e query	Si	No	??
Estendibilità	Molto granulare. Architettura a plug-in in molte parti.	Poco granulare. IQuerableProvider è molto complesso.	??
Disponibilià	Immediata	Da novembre in poi	da metà del 2008 in poi
Supporto a pagamento	Red Hat	Microsoft	Microsoft

Nota:
Si!...sono tutti e tre degli ORM...con feature più o meno evolute...ma la sostanza è quella.

Risorse su Linq to SQL

Giancarlo Sudano — Mon, 27 Aug 2007 10:58:43 GMT

Ok, si riprende.

Giusto per scaldare i motori, (visto che ho in previsione di scrivere qualcosa sull'uso di Linq to SQL, sia da un punto di vista architetturale che puramente implementativo) vi segnalo i link più interessanti sull'argomento.
Sottolineo che si tratta di Linq to SQL, qundi dell'ORM di casa Microsoft e non di Linq in generale:

Ovviamente gli articoli di ScottGu non potevano mancare, coprono molto bene quasi tutte le feature:

E se ne prevedono altri.

E poi è un piacere leggere Rico Mariani, uno dei "pezzi grossi" del framework su questa serie totalmente dedicata alle prestazioni:

E poi ancora Matt sulla costruzione di un provider interrogabile, che sarà la parte probabilmente più tosta:

Tecnicamente sono ottimi link, ma si sente fortemente la mancanza di linee guida su come utilizzare i contesti di persistenza di Linq 2 SQL, e quale impatto hanno sul disegno delle nostre applicazioni.
Pur trovando una montagna di risorse su come usare Linq to SQL in pochi snippet di codice, non si trova ancora niente su come "impiantarlo" in applicazioni real-world.

Vedremo di farci un pensierino, giusto?