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: Part 1: Introduction to LINQ to SQL Part 2: Defining our Data Model Classes Part 3: Querying our Database Part 4: Updating our Database Part 5: Binding UI using the ASP:LinqDataSource Control Part 6: Retrieving Data Using Stored Procedures Part 7: Updating our Database using Stored Procedures 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: Linq to SQL Performance - Part 1 Linq to SQL Performance - Part 2 Linq to SQL Performance - Part 3 Linq to SQL Performance - Part 4 Linq to SQL Performance - Part 5 E poi ancora Matt sulla costruzione di un provider interrogabile, che sarà la parte probabilmente più tosta: Building an IQueryable Provider - Part 1 Building an IQueryable Provider - Part 2 Building an IQueryable Provider - Part 3 Building an IQueryable Provider - Part 4 Building an IQueryable Provider - Part 5 Building an IQueryable Provider - Part 6 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?