blogs.ASPItalia.com

Entity Framework ed il mapping

Stefano Mostarda — Mon, 14 Jul 2008 22:34:00 GMT

Ormai utilizzo Entity Framework da quasi un anno, e presso un cliente lo sto facendo adottare perch� questo vuole utilizzare solo tecnlogia proprietaria Microsoft. LINQ To SQL non � abbastanza potente quindi la scelta � ovvia.
Quando mi ritrovo a spiegare Entity Framework l'argomento pi� complicato non � l'Object Tracking o il supporto per scenari su pi� layer, logici o fisici che siano, o l'EntitySql; l'argomento pi� complesso � il Mapping. Senza dubbio il mapping in un ORM � il concetto pi� semplice da capire, ma con Entity Framework nonostante il facile compito si � riusciti a colpire la classica mosca col bazzuca, ma tant'� e cos� ce lo teniamo.
All'inizio, ho utilizzato il designer in ctp ma la mia voglia di imparare era tale che dopo pochi giorni sono passato direttamente a fare le cose a manina. Passare da dei tool che ti creano tuto da video a scrivere un xml a mano � pura follia, ma ormai non riesco a farne a meno, il designer proprio non lo so usare :)
Alla lunga per� paga perch� scrivere il mapping a mano e verificare gli errori fa capire quali sono le necessit� di Entity Framework e fa pi� o meno intuire come lavora il motore.
Ai Community Days, stavo impazzendo con Roberto perch� lui non riusciva a riprodurre l'ereditariet� Table Per Type e io invece.... nemmeno :). Lui utilizzava il tool e io non sapevo nemmeno cosa stesse facendo quindi mi sono buttato sul file XML. Dopo un vago girare a vuoto, mi sono accorto che nel file SSDL (quello della descrizione dello storage e occhio ho detto storage e non database) non c'era la descrizione dell'associazione tra la tabella primaria e quella secondaria con i campi aggiuntivi. Dimenticando di descrivere quest'associazione, Entity Framework non sapeva come mettere in join le tabelle e generava un'eccezione. Qui si scatena un putiferio; le eccezioni di mapping sono la cosa pi� oscura del mondo; per la semplice mancanza dell'associazione siamo finiti per avere un messaggio di perdita di dati dovuta alla non conoscenza del lato C della tabella padre. Pensandoci bene, uno particolarmente malato forse potrebbe anche arrivare a capire l'errore ma non sono molto fiducioso.

Insomma, tutto questo per dire una cosa: fatevi i file XML a mano. Probabilmente la prima settimana riuscirete a mappare solo 4 tabelle sulle classi analoghe sputando anche svariato sangue, ma state tranquilli che lo sforzo verr� ampiamente ripagato dopo poco tempo. Personalmente adoro questa piccola applicazione che � una miniera di informazioni per il mapping.

Stay Tuned...

Tags: Entity Framework, ORM, .NET Framework 3.5, LINQ, LINQ to SQL

Continua a leggere Entity Framework ed il mapping.

Il nuovo speciale in arrivo su LINQ

Stefano Mostarda — Fri, 28 Mar 2008 10:37:00 GMT

Se � vero che alla follia non c'� mai fine allora non so veramente dove andremo a finire. Non bastavano 2 siti nuovi di zecca dedicati alle pi� grandi novit� di casa Microsoft degli ultimi anni? Non bastava uno speciale mastodontico su tutto il framework 3.5? Non bastava un Community After Hour durante il lancio di Visual Studio? Non bastavano articoli, script, focuson, blog?
Beh, la risposta �: NO.

Dalla prossima settimana arricchiremo la nostra offerta di contenuti aprendo le porte ad un nuovo format: lo screencast. Come � ormai nostra usanza, affronteremo questa nuova sfida con uno speciale. La sezione media esiste gi� da diverso tempo, ma contiene registrazioni di sessioni che abbiamo tenuto per le varie conferenze. Questa volta abbiamo deciso di fare qualcosa di apposito.

6 screencast su LINQ e tutti i suoi flavour dalla durata decisamente breve (10-15 minuti) e dal taglio esclusivamente pratico. Non posso nascondere una punta di orgoglio nel dire queste cose perch� il primo sito del network ad affrontare questa nuova avventura � LINQItalia.

Come sempre, anche se gli screencast li faccio io, non sono di certo il solo artefice di questo speciale; Alessio ha affrontato la parte Player (In Siverlight) mentre Daniele ha come sempre coordinato le attivit�.

Insomma, ad Aprile niente dolce dormire, ma tanti nuovi contenuti per la community :). E poi chiss�, se le cose vanno bene, mica ci si deve fermare qui ;)

Stay tuned...

Tags: .NET Framework 3.5, LINQ, LINQ to SQL, LINQ to XML, XML

Continua a leggere Il nuovo speciale in arrivo su LINQ.

LINQ To SQL ed il Fetching

Stefano Mostarda — Thu, 27 Dec 2007 09:23:00 GMT

Partiamo da un concetto: LINQ To SQL � fantastico. E' un ORM For Dummies nel senso che ha una facilit� di apprendimento ed utilizzo semplicemente impressionante ed una serie di feature comunque sufficienti per poterci basare un'applicazione. Molti definiscono LINQ To SQL un ORM For Dummies perch� limitato a SQL Server, non Persistence Ignorant e con feature molto ridotte rispetto a giganti come NHibernate; tuttavia, io credo sia solo invidia per l'intellisense in Visual Studio ed il Compile Time Checking delle query :).

Eppure, nonostante tutto, ci sono quelle cose che sembrano punture di zanzare ma in realt� sono pugnalate al cuore. La principale �: le politiche di fetching si possono impostare solo sul DataContext ed una sola volta. All'inizio, LINQ To SQL permetteva di decidere a livello di query come tirare gi� le associazioni dal db, se in eager o in lazy loading. Per default, le entit� associate venivano caricate in lazy con la possibilit� di cambiare, tramite LoadOptions, in eager. Questa possibilit�, in realt�, rappresentava un problema per il team di sviluppo che doveva gestire una serie di casistiche di caricamento eccessive, quindi � stata tagliata la testa al toro e si � spostato il tutto sul DataContext invece che sulla singola query.

Qui saltano fuori i doloretti. Se io volessi tirarmi gi� una fattura ed i suoi dettagli, e poi un cliente ed i suoi ordini (il tutto in eager loading), e volessi utilizzare lo stesso DataContext l'unica via � impostare a priori le politiche di fetching cio� quando si crea il DataContext. Infatti, se lo facessi nel metodo che esegue la query, mi ritroverei con una bella eccezione quando recupero i clienti perch� il fetching � stato impostato gi� una volta nel metodo che ritrova la fattura.

Come detto, l'unica via � impostare in fase di creazione del DataContext tutte le politiche di fetching che questo dovr� seguire. Ovviamente la cosa va fatta contesualizzata; se la si facesse generalizzata, si caricherebbero sempre gli ordini di un cliente anche se si vuole recuperare solo il suo dettaglio. Per fare questo, � la pagina stessa che deve inviare al DAL le informazioni su come caricare le cose che poi verrano cercate. Questo implica che se dobbiamo modificare una politica di fetching dobbiamo farlo in tutte le pagine coinvolte.

Alla fine, dopo averci ravanato un p� sopra, sono arrivato alla mia idea definitiva di come utilizzare LINQ To SQL in un 3 tier con tutti i compromessi che ne derivano, ma sar� argomento di un post entro le 48 ore :)

Stay Tuned...

Tags: .NET Framework 3.5, LINQ, ORM

Continua a leggere LINQ To SQL ed il Fetching.

LINQ To SQL ed un problema di null

Stefano Mostarda — Sun, 16 Dec 2007 22:09:00 GMT

L'altro giorno mi stavo dilettando scrivendo una query LINQ per estrarre il prossimo numero di fattura per l'anno in corso. La query � tutto sommato semplice:

(from c in MyDataContext.Invoice
where c.IssueDate.Year == DateTime.Now.Year
select c.Number).Max()

Ora il problema scatta per la prima fattura dell'anno. Infatti, il risultato della query da db � null poich� non esiste ancora una fattura per l'anno in corso. La conseguenza � che LINQ cerca di mettere null in un int (poich� il campo Number � int) ed il tutto scoppia. La soluzione � semplice, basta castare il campo Number a nullable ed usare GetValueOrDefault per avere il valore di default che desideriamo in caso di null.

(from c in MyDataContext.Invoice
where c.IssueDate.Year == DateTime.Now.Year
select (int?)c.Number).Max().GetValueOrDefault(1)

Stay tuned...

Tags: .NET Framework 3.5, LINQ

Continua a leggere LINQ To SQL ed un problema di null.

LINQ To SQL vs NHibernate

Stefano Mostarda — Sun, 25 Nov 2007 15:53:00 GMT

Durante il mio viaggio nel mondo degli ORM mi sto soffermando molto su LINQ To SQL e NHibernate e come strutturare un 3Tier con questi. NHibernate � tutt'altra bestia e come sappiamo tutti � infinitamente pi� potente rispetto a LINQ To SQL e rende lo sviluppo con Persistence Ignorance assolutamente semplice. Tuttavia, ci sono comunque delle cose che mi fanno preferire LINQ To SQL per molti scenari.

E-Commerce: un tipo di applicazione come questa necessita di query che vanno per il 95% a consultare il database e per il restante 5% a scrivere. Applicazioni del genere hanno un modello ad oggetti abbastanza semplice e non hanno bisogno di meccanismi di persistenza troppo complessi perch� spesso gli oggetti hanno un mapping 1:1 con le tabelle del db. In questi casi non scomoderei mai NHibernate perch� sarebbe come sparare con un cannone per colpire una zanzara, mentre LINQ To SQL esprime il suo massimo potenziale in questi scenari.

Community: una community ha forum, blog, articoli, script tutti riconducibili ad un modello a oggetti anche qui estremamente semplice. Ad esempio, un articolo ed un post sul forum o su un blog hanno molto in comune (Autore, data, soggetto, testo, ecc). Anche qui, vale lo stesso discorso per la categoria precedente meglio LINQ To SQL.

Gestionali: qui il discorso si complica; con questi tipi di applicazione e con l'avvento di ajax capita spesso che si possano creare maschere con tantissimi dati dentro ed un commit finale che deve persistere grafi complessi. In questo caso la scelta tra uno o l'altro dipende da quanto il mapping 1:1 imposto da LINQ To SQL sia accettabile. Io opterei per NHibernate quando la cosa � troppo gravosa mentre in altri casi LINQ To SQL � un'ottima scelta.

Le considerazioni che ho fatto, ovviamente, tengono conto solo delle problematiche relative al mapping senza tenere in considerazione prestazioni, tipo di database, supporto degli editor, ed altro ancora.

Detto questo, viva LINQ To SQL viva NHibernate, viva il mapping manuale, viva le applicazioni che funzionano :D.

Stay tuned...

Tags: .NET Framework 3.5, Architettura, LINQ, NHibernate, ORM

Continua a leggere LINQ To SQL vs NHibernate.

Linq non è solo interazione con il Database

Stefano Mostarda — Sun, 14 Oct 2007 21:54:00 GMT

Sto usando massivamente LINQ in questo periodo, vuoi per preparare gli script per la sezione, vuoi perch� lo trovo estremamente affascinante, vuoi perch� a volte non ho niente di meglio da fare che smanettarci un pochino :).

E' ovvio che la grande novit� che LINQ introduce � l'interazione tipizzata verso il database, vedi Linq to Sql ed il pi� ampio ADO.NET EF. Per� ridurre LINQ solamente a questi campi sarebbe estremamente riduttivo. Infatti la sua potenza di elaborazione di oggetti in memoria � molto elevata (INQ To Objects). Fare query su liste, di oggetti, fondere n liste, ricercare insiemi, cercare parole all'inteno di frasi, insomma tutte quelle operazioni che fino ad adesso si sono espresse tramite codice si possono esprimere con un linguaggio molto simile ad una query. La vera potenza di Linq secondo me sta li.

Questo anche perch� trovo LINQ To Sql ancora molto acerbo (anche se super-perfetto per certi scenari), e ADO.NET EF � ancora lontano. Questo � il principale motivo che mi ha spinto ad organizzare la rubrica nel mondo in cui lo � adesso, ovvero una approfondita introduzione alla potenza della sintassi LINQ, senza puntare dritti al database. Io credo che una volta vista la maggior parte della sintassi e analizzato come fare query su oggetti e su file xml fnalmente si smetter� di polemizzare sulle limitazioni di LINQ verso i database e si apprezzer� finalmente la sua eccezionale potenza in tutti gli altri campi (ovver� il restante 90% dell'applicazione).

Stay Tuned...

Tags: .NET Framework 3.5, LINQ

Continua a leggere Linq non è solo interazione con il Database.

ADO.NET Entity Framework e le colonne calcolate

Stefano Mostarda — Mon, 03 Sep 2007 20:03:00 GMT

Lo studio su Linq prosegue a gonfie vele, complice anche un treno da Roma a Milano che ha 90 minuti di ritardo.

Dopo aver studiato un p� le modalit� per fare le query, Lazy Loading, eager loading, ed altre cosine, sono passato agli aggiornamenti e qui mi sono scontrato con un problemino. Ho provato ad aggiungere un nuovo oggetto ad una tabella che aveva un campo calcolato e sqlserver mi restituiva una bella eccezione. Ovviamente, il problema risiedeva nel mapping che non considerava il fatto che il campo fosse calcolato. Il file l'ho generato tramite i tool appena usciti con la prima ctp quindi direi che ho scovato un bel bug :).

Per la cronaca, il problema si risolve recuperando la parte di definizione dello Storage Schema (SSDL) ed impostando sulla colonna in questione l'attributo StoreGeneratedPattern="computed". In questo modo l'sql generato dalla insert non prende in considerazione il campo calcolato e sqlserver � felice e contento ( e anche io :) ).

Stay Tuned...

Tags: ADO.NET, LINQ, .NET Framework 3.5

Continua a leggere ADO.NET Entity Framework e le colonne calcolate.

Linq To Entities ed il Lazy Loading

Stefano Mostarda — Sun, 02 Sep 2007 22:02:00 GMT

Fondamentalmente, ADO.NET Entity Framework mi piace e parecchio pure. A parte gli errori di impostazione che secondo me sono nella maggior parte dei casi ignorabili (mancanza di Persistence Ignorance su tutti), direi che nel complesso le basi per affacciarsi al mondo ORM con una prima versione decente ci sono.

Tuttavia ogni tanto vedo cose che trovo strane. Per default, quando si carica un'entit�, tutte le entit� associate non vengono caricate subito, ma solo quando vi si accede. Quindi, quando si carica un'entita Customer, non si caricano anche i suoi ordini. Quando si vuole accedere ai suoi ordini si interroga la propriet� Orders; insomma qualcosa come cust.Orders.

Ebbene, a meno che non mi sia perso qualcosa, il procedimento non � solamente questo. Infatti, l'entita va caricata esplicitamente chiamando il metodo Load; quindi, prima si chiama cust.Orders.Load(), e poi si possono scorrere i dati. Ora, la cosa non mi piace proprio; se accedo alla propriet� vuol dire che la voglio caricare, quindi perch� doverlo fare esplicitamente?

Spero tanto di essermi perso qualcosa, intanto continuo a cercare, ma se non trover� nulla che mi smentir�, rimmarr� un tantinello basito.

Stay tuned...

Tags: ADO.NET, LINQ, LINQ to Entities, .NET Framework 3.5, Entity Framework, ORM

Continua a leggere Linq To Entities ed il Lazy Loading.

Linq e l'esecuzione delle query

Stefano Mostarda — Sun, 26 Aug 2007 09:52:00 GMT

Ormai anche i sassi sanno che Visual Studio 2008 � alle porte. A fine febbraio uscir� la RTM. Questo significa che se fino ad adesso si � giocato o si � provato a capire solo la base di come funzionano le cose con LINQ, � arrivato il momento di fare sul serio.

Stamattina complice il jetleg di 5 ore mi sono svegliato presto e ovviamente tra il dover pulire casa, uscire fuori con 30 gradi, subirmi le sempre pi� pallose trasmissioni di Formula 1 ho scelto un p� di studio di LINQ (eh lo so son malato che ci posso fare :).

Una cosa che mi son chiesto �: quando LINQ esegue la query? Non che la cosa sia particolarmente importante, ma sapere come funziona fa sempre bene. Armato di VS2008 e del fido profiler mi sono messo all'opera ed ho tirato gi� questo codice:

dbcontext db = new dbcontext();
var q = From t in db.table where t.field > 10 select t;
mylistview.DataSource = q;
mylistview.DataBind();

Queste 4 righe di codice comportano l'esecuzione della query solo nel momento in cui viene fatto il databind alla listview. In questo caso banale, la cosa non � importante, ma se si incrementano delle variabili nella query e si pretende che queste siano incrementate prima di fare il databind, allora questa modalit� rappresenta un problema. Per ovviare al problema, basta circondare la query tra parentesi ed invocare un semplice ToList() per far eseguire subito la query.

var q = (From t in db.table where t.field > 10 select t).ToList();

P.S. Il fatto che LINQ mi interessi tanto non � dovuto solo alla sua potenza e alla RTM incombente... A buon intenditor poche parole ;).

Stay Tuned...

Tags: .NET Framework 3.5, LINQ

Continua a leggere Linq e l'esecuzione delle query.