AZ - Il blog di Andrea Zani

L'entity Framework e i vincoli FOREIGN KEY

L'entity framework rende felice. Ti fa vedere il mondo dei database sotto un'altra ottica. Le complicazioni create dai soliti esperti di struttura dei database fanno ora sorridere, anzi, li si incita a complicare maggiormente la struttura delle tabella per normalizzazioni fino al quinto livello.

- Il terzo livello basta!
- No, andiamo fino al quinti livello di normalizzazione! - possono ora affermare i dev sorseggiando un caffè alle loro spalle.

A parte queste ciance, una delle attenzioni che si devono avere quando si usa l'Entity Framework è quando si cancellano delle entity dal database quando sono in gioco Foreign key e amenità simili. Inoltre, la cancellazione di una entità non elimina - giustamente - di suo eventuali proprietà collegate uno-a-uno con un'altra tabella (sempre che sul db non ci siano regole varie, ma in questo caso di deve prestare attenzione, perché la cache interna dell'Entity Framework la vedrà ancora presente). Buona regola, nel caso di voler cancellare tutti i record coinvolti in una entità, scrivere:

using (pubsModel.pubsEntities2 context = new pubsModel.pubsEntities2())
{
    var padre = context.Canc_Padre.Include("Canc_Figlia").First();
    var figlia = padre.Canc_Figlia;
    context.DeleteObject(figlia);
    context.DeleteObject(padre);
    context.SaveChanges();
}

In questo caso le tabelle di chiamano Canc_Padre e Canc_Figlia. L'ordine di cancellazione dev'essere anche quello mostrato (prima la tabella figlia e poi la padre), perché la cancellazione dell'entità padre farebbe perdere il collegamento con il record da cancellare con la necessità di una nuova query di select di ricerca.

Ma nel caso delle relazioni molti-a-molti? Prendiamo d'esempio un classico schema con tre tabelle:

authors
books
authorsbooks

Le prime due sono le classiche tabelle che conterranno i dati, la terza quella che collega i dati delle due.

Scrivendo questo codice:

using (pubsModel.pubsEntities2 context = new pubsModel.pubsEntities2())
{
    var coll = (from au in context.authors
               where au.name=="..."
               select au).First();
    context.DeleteObject(coll);
    context.SaveChanges();
}

Otterremo il classico errore:

L'istruzione DELETE è in conflitto con il vincolo REFERENCE "FK_authors_books_authors". Il conflitto si è verificato nella tabella "dbo.authorsbooks", column 'id_author' del database "pubs".

Per evitare questo problema, cioè cancellare il record dalla tabella authors e ogni suo riferimento dalla tabella authorsbooks, dovremo invece scrivere:

using (pubsModel.pubsEntities2 context = new pubsModel.pubsEntities2())
{
    var coll = (from au in context.authors.Include("books")
               where au.name=="..."
               select au).First();
    context.DeleteObject(coll);
    context.SaveChanges();
}

Se volessimo cancellare anche il record in book, dovremo fare come sopra: recuperata l'entity usare il DeleteObject.

PS: ieri sera ho dovuto aspettare venti minuti il pullman per tornare a casa.

Tags: Database

Data Service Viewer

Interessante questo tool. Anche se Astoria è una tecnologia che mi mette parecchi dubbi (dubbi che non voglio per ora divulgare qui) la trovo interessante. E se c'è un tool che permette di provare le richieste http in modo facile e che ti dà anche una mano, ben venga.

E' un exe scritto in .net. Alla prima richiesta richiede l'endpoint dove astoria è in attesa, per esempio:

http://localhost:1035/WebSiteEntity2/WebDataService.svc

Nel codice di questo ado.net web data service, è necessario obbligare quali entità possono essere utilizzate e come:

public class WebDataService : DataService<pubsModel.pubsEntities2>
{
    public static void InitializeService(IDataServiceConfiguration config)
    {
        config.SetEntitySetAccessRule("*", EntitySetRights.All);
        config.SetServiceOperationAccessRule("*", ServiceOperationRights.All);
    }
}

Qui ho specificato che è possibile operare su tutte le entità e che posso farci di tutto tra queste scelte possibili.

Ok, avviata la web application con questo nuovo oggetto, possiamo utilizzare il tool prima citato che il nome significativo "Data service viewer". Inserito l'endpoint, ecco la schermata:

Ma l'utilità vera è nella possibilità di provare le query avendo il supporto per l'intellisense durante la scrittura:

Qui si scopre un piccolo problema. L'elenco delle scelte possibile è selezionabile con i tasti cursore e la scelta è selezionabile solo con il tasto invio e con il mouse mentre il tasto tab manda al pulsante per l'esecuzione della query.

Lazy Loading con l'Entity Framework

Anche se qualcuno afferma il contrario, non cito la fonte, abbiamo a disposizione più metodi per caricare entità collegate. In tutti questi post dedicati all'Entity Framework ho fatto sempre esempio che riguardavano più tabelle (~entità) collegate.

Possiamo fare in modo che sia lo stesso Entity Framework a caricare con una query il tutto grazie a Include:

var coll=from c in EntityContext.Articles.Include("Authors")
select c;
foreach (var item in coll)
{
Response.Write(item.Title);
Response.Write(item.Authors.Name);
}

Oppure possiamo forzare il caricamente delle entità collegate, in questo caso Authors, ad ogni richiesta della stessa:

var coll=from c in EntityContext.Articles
select c;
foreach (var item in coll)
{
Response.Write(item.Title);
if (item.AuthorsReference.IsLoaded) // Controlla se già presente in memoria
    Response.Write(item.AuthorsReference.Value.Name);
else
{
    item.AuthorsReference.Load();
    Response.Write(item.Authors.Name);
}
}

In quest'ultimo caso all'inizio viene eseguita una query che richiede solo la lista degli Articles. Quindi viene verificato che l'entità per gli Authors non sia già presente in memoria; se presente la visualizza direttamente, altrimenti esegue una query al database.

Il numero di query inviate al database è N+(numero di autori richiesti differenti). Ipoteticamente, se tutti gli articoli fossero collegati ad un solo autore, il numero di query inviate al database sarebbero due.

PS: scusate la brevità ma il tempo è tiranno. O Tiràno?

4 desktop virtuali su Windows

Una peculiarità che ho sempre apprezzato nei desktop manager di Linux è la possibilità di dividere la zona di lavoro su più desktop virtuali. Leggo ora che è presente questo tool che lo permette anche su Windows. Scaricato e avviato. Funziona discretamente, ed è veloce e pesa poco. Il problema è un altro: non permette i passaggi di finestre tra un desktop all'altro con la stessa facilità che permette Gnome o Kde: vengono sì create più arie di lavoro, ma queste non sembrano poter comunicare.

Peccato.

A volte ritornano... GridView vs Repeater vs ListView vs Custom

Sono passati anni? Parecchio tempo fa avevo confrontato le prestazioni nel binding dei dati tra i più noti webcontrol. Ecco un refresh, questa volta con il Framework 3.5 e con lo scontro tra:

Gridview
Repeater
ListView
Custom code

Chiunque un po' smaliziato con il .net saprà già chi vince e chi è il peggiore tra questi. Ma per i novizi è sempre meglio saperlo. Innanzitutto, il codice per il popolamento delle tabelle html è il seguente:

List<Person> p;
p = new List<Person>(200);
for (int i = 0; i < 200; i++)
p.Add(new Person { Id=i, Age=i, Description="Desc "+i.ToString(), Name="Name "+i.ToString() });

Il gridview crea la table html con questo codice:

<asp:GridView ID="gw1" EnableViewState="false" runat="server" AutoGenerateColumns="false">
    <Columns>
        <asp:BoundField DataField="id" />
        <asp:BoundField DataField="name" />
        <asp:BoundField DataField="age" />
        <asp:BoundField DataField="description" />
    </Columns>
</asp:GridView>

Per il repeater abbiamo:

<asp:Repeater ID="rp1" runat="server" EnableViewState="false">
<HeaderTemplate><table border="1"></HeaderTemplate>
<FooterTemplate></table></FooterTemplate>
<ItemTemplate>
<tr>
    <td><%# Eval("id") %></td>
    <td><%# Eval("name") %></td>
    <td><%# Eval("age") %></td>
    <td><%# Eval("description") %></td>
</tr>
</ItemTemplate>
</asp:Repeater>

Ma siccome vogliamo ottimizzare un po', possiamo scrivere:

Ecco il ListView, semplice:

<asp:ListView ID="lw1" runat="server" EnableViewState="false">
    <LayoutTemplate>
        <table border="1">
            <asp:Panel ID="itemPlaceholder" runat="server" />
        </table>
    </LayoutTemplate>
    <ItemTemplate>
        <tr>
            <td><%# Eval("id") %></td>
            <td><%# Eval("name") %></td>
            <td><%# Eval("age") %></td>
            <td><%# Eval("description") %></td>
        </tr>
    </ItemTemplate>
</asp:ListView>

E ottimizzato:

E infine creiamo la griglia da codice con un banale StringBuilder da codice:

var sb = new StringBuilder(10000);
sb.Append("<table border='1'>");
for (int i = 0; i < p.Count; i++)
{
    sb.Append("<tr><td>");
    sb.Append(p[i].Id);
    sb.Append("</td><td>");
    sb.Append(p[i].Name);
    sb.Append("</td><td>");
    sb.Append(p[i].Age);
    sb.Append("</td><td>");
    sb.Append(p[i].Description);
    sb.Append("</td></tr>");
}
sb.Append("</table>");
pn1.Controls.Add(new LiteralControl(sb.ToString()));

pn1 è un panel. Ma vediamo le prestazioni (medie):

GridView	*0.122s*
Repeater	0.058s
Repeater ottimizzato	0.046s
ListView	0.059s
ListView ottimizzato	0.047s
Custom code	0.006s

A parte la tabella scritta con lo StringBuilder che mediamente risulta otto volte più veloce del ListView e del Repeater, la sorpresa è proprio il ListView che risulta veloce quanto il Repeater. In poche parole? Il DataGrid, DataList, DataGrid e Repeater sono diventati obsoleti e inutili dato il ListView non solo sostituisce in tutto questi webcontrol, ma ha prestazioni più che buone.

Inoltre, per avere un discreto guadagno, anche la visualizzazione con il casting di tipo nella colonna, invece dell'Eval, è consigliato.

Tags: ASP.NET, ASP.NET 2.0, ASP.NET 3.5, Databinding, Datagrid, GridView

L'Entity Framework e l'ObjectDataSource

Anche se con l'SP1 del Framework 3.5 è stato introdotto il nuovo EntityDataSource per collegare direttamente questi nuovi oggetti a web control come il ListView o il GridView, l'utilizzo dell'ObjectDataSource rimane sempre la soluzione migliore: come dice Daniele, i datasource come l'SqlDataSource e compagnia bella sono solo veramente utili per le demo.

Di base non ci sono problemi. Solo di base però. Quando si cerca di fare qualcosa di più complesso saltano sempre fuori casini vari. Messo nella pagina un ListView collegato ad un bel ObjectDataSource che utilizza una classe apposita che ritorna le entità (nel mio caso con l'ausilio dell'Entity Framework) non ci sono problemi: persino altre entità memorizzate in proprietà vengono visualizzate correttamente. Come nell'esempio già visto:

I problemi nascono quando entrano in gioco gli update e gli insert. Come scritto sopra, di base, cioè con proprietà con tipi non complessi, non ci sono problemi. Definendo nell'InsertMethod dell'ObjectDataSource una nostra funzione come la seguente, tutto funziona:

Che bello! Eh sì, ma l'entità qui trattata ha anche come proprietà la collection di Book collegati all'autore secondo il seguente schema:

Per visualizzare il tutto in modalità edit si incotrano le prime rogne ma risolvibile. Ma cosa viene passato al metodo InsertAuthor prima mostrato? Tutto, tranne, ovviamente, eventuli aggiunte ai book. Qui l'esempio è un po' forzato, ma un caso reale potrebbe essere la creazione di un nuovo utente e il collegamento ad esso di una o più role per autorizzazione varie (visualizzate in modalità edit come lista con checkbox).

Come inviare il tutto in modo corretto a quella funzione o quasi?

Io ho solo trovato un espediente, ma spero ci siano soluzioni più semplici che finora mi sono sfuggite. Utilizzando l'evento On_ItemInserting dell'ListView possiamo forza l'aggiunta di tutte le informazioni utili:

protected void lw_authors_ItemInserting(object sender, ListViewInsertEventArgs e)
{
// In Values troviamo tutti i valori letti dal objectdatasource (BoundColumn, Bind, ecc...)
// Inserisce un campo aggiuntivo perla data presente nel db ma non del ListView
e.Values.Add("CreationData", DateTime.Now);
var books = new System.Data.Objects.DataClasses.EntityCollection();
// Metodi che richiedono le entità da collegare
books.Add( AZ.GetBookFromId(1) );
books.Add( AZ.GetBookFromId(2) );
e.Values.Add("Books", auths);
}

Innanzitutto, l'objectdatasource espone la connection come EntityConnection, quindi perché possa essere riconosciuta dobbiamo inserire tutti gli item selezionati in questa collection. Sembra tutto ok, in questo modo all'evento di inserimento dovrebbe essere passato il tutto correttamente. Dovrebbe! Richiamato questo codice si ha come output un errore chiarissimo in merito proprio al momento dell'Add:

The object could not be added to the EntityCollection or EntityReference. An object that is attached to an ObjectContext cannot be added to an EntityCollection or EntityReference that is not associated with a source object.

Allora ecco l'escamotage:

protected void lw_users_ItemInserting(object sender, ListViewInsertEventArgs e)
{
    // ...
    var books = new System.Data.Objects.DataClasses.EntityCollection<Book>();
    books.Add(new Book { Id = 1 });
    books.Add(new Book { Id = 2 });
    e.Values.Add("Books", auths);
}

Creo due nuove classi Book dove inserisco gli Id dei valori selezionati nell'interfaccia grafica (qui inseriti da codice per rendere il tutto più semplice). Ora il codice per l'inserimento dovrebbe accettare anche questi dati aggiuntivi, ma ecco il secondo problema della giornata: quelle entità verrebbero trattate come nuovi oggetti e inseriti nuovamente nel database. Ecco dunque l'ultima modifica al codice, questa volta nella funzione di inserimento:

[System.ComponentModel.DataObjectMethod(System.ComponentModel.DataObjectMethodType.Insert)]
public static void InsertAuthor(Author author)
{
using (TestEntitiesModel.TestEntitiesCode context = new TestEntitiesModel.TestEntitiesCode())
{
var coll = user.Books.Select(r => r.Id).ToArray<int>();
user.Books.Clear();
foreach (var item in coll)
    user.Books.Add( context.Books.Where( r=>r.Id==item ).FirstOrDefault() );
// Oppure
// foreach (var item in coll)
  // user.Books.Add( context.GetObjectbyKey( item ) );
  context.addAuthors(author);
context.SaveChanges();
}
}

E tutto funziona correttamente. Ma spero ci siano soluzioni più immediate e semplici. Vero? Ditemi di sì! :(

SP vs Linq vs Entity Framework in scrittura

La sola sicurezza che avevo era di quanto Linq e l'Entity Framework fossero più lenti. Mi preparo un banale test per l'inserimento di un buon numero di record in un database Sql server 2005 per un benchmark personale. Creo due tabelle collegate dalla struttura molto semplice:

Il mio test è molto banale: creare un array casuale di 100 padri, e ogni padre un array casuale di 100 figli. Gli sfidanti e le armi utilizzate sono i seguenti:

Collection tradizionale e stored procedure (una per ogni tabella) richiamata con il Prepare del Command per il massimo delle prestazioni.
Collection inserita direttamente in un DataContext creato da Visual Studio 2008.
Collection inserita direttamente nelle collection create dall'Entity Framework.

Ecco di seguito il DataContext usato da Linq:

E l'Entity Framework creato sempre da VS2008:

Avvio più volte i test per ogni tecnologia utilizzata. La media è la seguente:

Stored procedure	Linq to Sql	Entity Framework
6.75s	20.60s	12.93s

Sulla maggiori performance dell'inserimento diretto da codice con le stored procedure, come già detto, non ne avevo il minimo dubbio: il tutto è ottimizzato al meglio, ed ho cercato anche da codice di ottimizzare il più possibile la creazione di oggetti e il passaggio di parametri. La delusione è stata invece per Linq, che le prende sonoramente anche dall'Entity Framework che si dimostra molto più efficiente del tradizionale Linq to Sql.

Leggendo con il Profiler le query inviate da Linq to Sql e dall'Entity Framework, si notano alcune differenze nelle query di inserimento create:

-- Linq to Sql
-- Inserimento nella tavella 'Padri'
exec sp_executesql N'INSERT INTO [dbo].[Padri]([NomePadre])
VALUES (@p0)
SELECT CONVERT(Int,SCOPE_IDENTITY()) AS [value]',N'@p0 nvarchar(7)',@p0=N'Padre 1'
--
-- Inserimento nella tabella 'Figli'
exec sp_executesql N'INSERT INTO [dbo].[Figli]([IdPadre], [NomeFiglio])
VALUES (@p0, @p1)
SELECT CONVERT(Int,SCOPE_IDENTITY()) AS [value]',N'@p0 int,@p1 nvarchar(9)',@p0=400,@p1=N'Padre 1 1'

---- Entity Framework
-- Inserimenti nella tabella 'Padri'
exec sp_executesql N'insert [dbo].[Padri]([NomePadre])
values (@0)
select [Id]
from [dbo].[Padri]
where @@ROWCOUNT > 0 and [Id] = scope_identity()',N'@0 nvarchar(7)',@0=N'Padre 1'
--
-- Inserimento nella tabella 'Figli'
exec sp_executesql N'insert [dbo].[Figli]([IdPadre], [NomeFiglio])
values (@0, @1)
select [Id]
from [dbo].[Figli]
where @@ROWCOUNT > 0 and [Id] = scope_identity()',N'@0 int,@1 nvarchar(9)',@0=1600,@1=N'Padre 1 1'

La cosa che salta all'occhio subito è il differente modo di prendere l'id del record appena inserito e sembra, e lo ripeto, sembra, che sia più performante quello utilizzato dall'Entity Framework anche se, la differenze in peggio tra le due tecnolgie, potrebbero essere invece a livello di codice del Framework nelle sue creazioni delle query.

Ora è tardi per investigare oltre. Ho fatto appena un viaggio di circa tre ore di pullman e sono stanco... Ma prima, si possono tirare conclusioni? Il mio test può essere un caso reale di codice? La stanchezza mi sta spegnendo la ragione... mi fermo qui

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

Ho fatto pace con l'Entity Framework: un minimo di cache!

Nel post precedente riscontravo che come due richieste sulla stessa entità venisse gestita dall'Entity Framework in maniera - per me - strana, o per meglio dire, non in modo ottimizzato, perché eseguiva due query perfettamente identiche al database. Ovviamente, come mi ha fatto notare giustamente Daniele e Cristian, è un comportamento legittimo, e anzi, sarebbe stato strano se avveniva come io lo avevo immaginato.

Scopro solo ora che nativamente esiste una sorta di cache all'interno dell'Entity Framework, ma la cosa deve essere forzata dal programmatore. Riprendendo l'esempio del mio blog precedente, si deve scrivere:

using (TestModel.TestEntities context = new TestModel.TestEntities())
{
            int colore = 2;
            var a = new TestModel.Articles();
            a.Article = "Art3 " + DateTime.Now.ToString();
            var c = context.Colors.Where(w => w.Id == colore).First();
            a.Colors = c;
            context.AddToArticles(a);
            a = new TestModel.Articles();
            a.Article = "Art4 " + DateTime.Now.ToString();
            //////////////////////////////////////
            object obj = null;
            context.TryGetObjectByKey(
                new System.Data.EntityKey(
                    string.Format("{0}.{1}", context.DefaultContainerName, "Colors"),
                    "Id",
                    colore), out obj);
            if (obj != null)
            {
                // E' presente tra gli oggetti
                c = (TestModel.Colors)obj;
            }
            else
            {
                // Rifaccio la query (*)
                c = context.Colors.Where(w => w.Id == colore).First();
            }
            /////////////////////////////////////
            a.Colors = c;
            context.AddToArticles(a);
            context.SaveChanges();
}

A venirmi in aiuto ci pensa la funzione TryGetObjectByKey che permette di cercare un oggetto per la sua key all'interno del context attuale utilizzato per l'entity framework. La sintassi è un po' intricata, ma risolve un sacco di dubbi. Ora, avviando l'esempio con il profiler avviato, vedo che viene eseguita una sola query per recuperare l'entity del colore...

Ma il TryGetObjectByKey non solo è in grado di prendere il valore se è già stata trattata, ma esegue lui stesso una query nel caso il valore non fosse presente. Il codice qui sopra potrebbe essere scritto in modo più semplice:

using (TestModel.TestEntities context = new TestModel.TestEntities())
{
            int colore = 2;
            var a = new TestModel.Articles();
            a.Article = "Art3 " + DateTime.Now.ToString();
            TestModel.Colors c;
            object obj = null;
            context.TryGetObjectByKey(
                new System.Data.EntityKey(
                    string.Format("{0}.{1}", context.DefaultContainerName, "Colors"),
                    "Id",
                    colore), out obj);
            c = (TestModel.Colors)obj;
            a.Colors = c;
            context.AddToArticles(a);
            a = new TestModel.Articles();
            a.Article = "Art4 " + DateTime.Now.ToString();
            obj = null;
            context.TryGetObjectByKey(
                new System.Data.EntityKey(
                    string.Format("{0}.{1}", context.DefaultContainerName, "Colors"),
                    "Id",
                    colore), out obj);
            c = (TestModel.Colors)obj;
            a.Colors = c;
            context.AddToArticles(a);
            context.SaveChanges();
}

(*) Il codice non viene mai eseguito.

Entity framework... un minimo di cache faceva schifo?

Leggero. Continuano dei test a tempo perso con l'entity framework. Siccome volevo legare delle proprietà ad una tabella per vedere il comportamento dell'EF (lo chiamo così amichevolmente perché inizio ad avere confidenza con questa tecnologia), ho creato una struttura simile a questa:

L'entity framework crea il tutto in modo corretto:

Nella tabella colors sono presenti dei record così composta:

Id	Color
1	Black
2	White
3	Red

Per inserire in Articles nuovi record con un colore corrispondente, mi basta scrivere il codice:

using (TestModel.TestEntities context = new TestModel.TestEntities())
        {
            var a = new TestModel.Articles();
            a.Article = "Art " + DateTime.Now.ToString();
            var c = context.Colors.Where(w => w.Color == "White").First();
            a.Colors = c;
            context.SaveChanges();
        }

Tutto funziona bene. Con il profiler vedo che esegue una prima query per sapere l'id del colore che sarà poi utilizzato per l'inserimento nella tabella Articoles. A chiunque sarebbe venuto lo stesso sospetto che è venuto a me: nel caso caso di inserimento di più oggetti Articles, avendo richiedendo lo stesso colore, come si comporta l'EF?

Ipotizzando questo codice:

using (TestModel.TestEntities context = new TestModel.TestEntities())
{
    string colore = "White";
    var a = new TestModel.Articles();
    a.Article = "Art " + DateTime.Now.ToString();
    var c = context.Colors.Where(w => w.Color == colore).First();
    a.Colors = c;
    context.SaveChanges();
    a = new TestModel.Articles();
    a.Article = "Art2 " + DateTime.Now.ToString();
    c = context.Colors.Where(w => w.Color == colore).First();
    a.Colors = c;
    context.SaveChanges();
}

E' per due volte richiesto il colore bianco. Avvio il codice, il tutto è inserito correttamente. Guardo con il profiler... delusione: esegue per ben due volte la query per ottenere l'id del colore. Una possibile soluzione? Crearsi una logica interna di cache... ok, ma un minimo di cache delle entità l'avrei gradita.

Entity Framework e il namespace EntityClient

Sabato pomeriggio. L'entity framework permette, grazie alle classi contenuti nel namespace EntityClient, la connessione e l'esecuzione di query direttamente sulle entity, come se si trattasse di un database. Riferendomi sempre a grandi linee agli esempi esposti qui e qui, ecco un banale esempio di utilizzo delle classi di questo namespace:

using (System.Data.EntityClient.EntityConnection conn = new System.Data.EntityClient.EntityConnection("name=TestEntitiesCode"))
{
conn.Open();

System.Data.EntityClient.EntityCommand comm= conn.CreateCommand();
comm.CommandText = "select na.Id, na.Names1, na.Books from TestEntitiesCode.Names as na";
System.Data.EntityClient.EntityDataReader re = comm.ExecuteReader(System.Data.CommandBehavior.SequentialAccess);
while (re.Read())
{
Response.Write(string.Format("{0}, {1} = ",
re["Id"], re["Names1"]));
ShowChildren(re["Books"] as System.Data.Common.DbDataReader);
Response.Write("<br />");
}
re.Close();
}

private void ShowChildren(System.Data.Common.DbDataReader children)
{
while (children.Read())
{
Response.Write("[[");
System.Data.IExtendedDataRecord columns = children as System.Data.IExtendedDataRecord;
for (int i = 0; i < columns.FieldCount; i++)
Response.Write(columns[i].ToString() + ", ");
Response.Write("]]");
}
}

Due parole sulla sintassi. In EntityConnection dobbiamo specificare il nome della classe del nostro model creato con VS2008 (nel dettaglio, aperto il model in VS2008 è sufficiente leggere la proprietà "Entity Container" nelle properties. Nell'esempio viene usata il datareader. Per le proprietà dirette come l'id e il name dell'entità Names, possiamo accedere direttamente con il nome stesso, ma in caso volessimo accedere, come nell'esempio, a una collection di entity come la lista dalla tabella Books, dobbiamo complicare un po' le cose. L'oggetto presente in re["Books"] è System.Data.Query.ResultAssembly.BridgeDataReader ma possiamo passarlo come un DbDataReader come nell'esempio.

In ShowChildren possiamo anche andare oltre, leggendo il tipo per ogni column e agire di conseguenza. Ma non ho approfondito oltre ed è sabato anche per me. Comunque, il risultato del codice è il seguente:

1, Andrea = [[1, Book 1, ]]
2, Andrea2 = [[2, Book 2, ]][[3, Book 3, ]]
3, Andrea3 = [[4, Book 2, ]][[5, Book 3, ]]

Andando a vedere con il Profiler se ci fossero ancora sorprese, troviamo la query già spiegata precedentemente.

Entity Framework e l'sql generato

Una torna a casa per qualche giorno di ferie e si becca il maltempo. Qualcuno crede alla sfortuna, altri al destino... non me ne importa niente: il problema è che c'è brutto tempo!

Allora per ammazzare un po' il tempo prima di pranzo cosa c'è di meglio che giocare con leggerezza ancora con l'Entity Framework?

Dopo che nel post precedente ho fatto vedere un banale inserimento, ecco come visualizzare i dati inseriti:

using (TestEntitiesModel.TestEntitiesCode context = new TestEntitiesModel.TestEntitiesCode())
{
var coll = from t in context.Names.Include("Books")
select t;
gw1.DataSource = coll;
gw1.DataBind();
}

Sempre con la sintassi Linq, faccio una select del contenuto della Entity Names e con l'include, voglio anche che sia popolata la collection dei Books. Il GridView nel codice html è il seguente:

<asp:GridView ID="gw1" EnableViewState="false" runat="server" AutoGenerateColumns="false">
<Columns>
<asp:BoundField DataField="Id" />
<asp:BoundField DataField="Names1" />
<asp:TemplateField>
<ItemTemplate>
<asp:GridView ID="gw_book" runat="server" DataSource='<%# Eval("Books") %>'>
</asp:GridView>
</ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>

Il risultato è il seguente:

Ma la mia grande curiosità è che comando sql è stato inviato a Sql Server. Armato di Profiler vado a curiosare e scopro una query alquanto bizzarra, almeno per me:

SELECT
[Project2].[Id] AS [Id],
[Project2].[Names] AS [Names],
[Project2].[C1] AS [C1],
[Project2].[C2] AS [C2],
[Project2].[Id1] AS [Id1],
[Project2].[Title] AS [Title]
FROM ( SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Names] AS [Names],
1 AS [C1],
[Project1].[Id] AS [Id1],
[Project1].[Title] AS [Title],
[Project1].[C1] AS [C2]
FROM [dbo].[Names] AS [Extent1]
LEFT OUTER JOIN (SELECT
[Extent2].[NamesId] AS [NamesId],
[Extent3].[Id] AS [Id],
[Extent3].[Title] AS [Title],
1 AS [C1]
FROM [dbo].[NamesBooks] AS [Extent2]
INNER JOIN [dbo].[Books] AS [Extent3] ON [Extent3].[Id] = [Extent2].[BooksId] ) AS [Project1] ON [Extent1].[Id] = [Project1].[NamesId]
) AS [Project2]
ORDER BY [Project2].[Id] ASC, [Project2].[C2] ASC

Ancora una volta avevo pensato male. Avevo immaginato che facesse una prima query e quindi n eventuali per la tebella figlia, e invece ha creato un unico comando con sotto query in modo molto furbo.

Il risultato della query lanciata così come appare è il seguente:

E' lui da codice poi a fare il distict per la collection Names e con le colonne virtuali create, C1 e C2 utilizzate in caso di più tabelle figlie.

Mi piace l'Entity Framework. Ne so ben poco, ma mi piace!

L'entity framework, e il Framework 3.5 senza SP 1

Come ho detto ieri ciò che mi piace è l'entity framework. Ma se creo un progetto web con VS2008 e SP1 che utilizza questi nuovi oggetti, e lo eseguo su un server con il Framework 3.5 senza SP1, funziona? Ne discutevo ieri con David. Sinceramente pensavo di sì, perché credevo che fosse tutta opera di VS2008 che, come il DataContext e Linq, crea in automatico le classi di supporto e il tutto che consente di lavorare con le entity.

Mi sbagliavo: faccio delle prove e il progetto non parte nemmeno perché non trova delle dll. Ecco le nuove inserite nel web.config della web application:

<add assembly="System.Data.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
<add assembly="System.Data.Entity.Design, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />

Andando ancora più in dettaglio, si può vedere la nuova stringa di connessione in caso di utilizzo dell'entity framework:

E il provider EntityClient.

[OT] Un anno fa...

... rimanevo allibito nel vedere questa offerta di connessione a Internet a 15 Lev, circa 7 euro al mese per una 2MBit! All'epoca pagavo quasi 20 euro con la Telecom!

Mi è piaciuta Sofia, e al cirillico ci si doveva solo abituare...

Tags: Off Topic

Sql Server 2008 e Visual Studio 2008 SP1

Mentre c'è gente che come bistecche ai ferri si rosola al sole - mentre io sono rimasto in città e sono più bianco di Casper e non ho nemmeno vicino Christina Ricci - ecco che questi due prodotti li ho finalmente installati. Fa una certa impressione vedere l'intellisense e il debug con il Managment Studio di Sql (solo, purtroppo, per db su 2008):

E trovare, finalmente, l'Entity Framework. E piacevole vedere che, con questa banalissima struttura, i vantaggi che si avranno poi con il codice:

Importato tutto in VS2008 nell'oggetto "ADO.Net Entity Data Model" ho il risultato:

Da solo VS2008 è stato in grado di creare le entità con il corretto mapping. Vediamo che cosa posso scrivere ora:

TestModel.TestEntities context = new TestModel.TestEntities();
TestModel.names n = new TestModel.names();
n.name = "AZ";
TestModel.books b = new TestModel.books();
b.title = "Book 1";
n.books.Add(b);
context.AddTonames(n);
context.SaveChanges();

Avviato, mi sono trovato il tutto mappato correttamente nelle tabelle:

SELECT * FROM [names]
SELECT * FROM [books]
SELECT * FROM [names_books]

id name
----------- --------------------------------------------------
5 AZ

(Righe interessate: 1)

id title
----------- --------------------------------------------------
4 Book 1

(Righe interessate: 1)

id_name id_book
----------- -----------
5 4

(Righe interessate: 1)

Ma che ci si va a fare in ferie quando si hanno queste belle sorprese dai programmatori Microsoft? Ma chi desidera ora acque cristalline o montagne? Perché dovrei desiderare di poter andare con la mia bici? Perché dovrei stare ad alta quota che c'è pure fresco quando invece posso divertirmi con l'entity framework? Il debug di Sql 2008 mi farà compagnia in questi giorni, alla faccia vostra!

[OT] Dove non sono andato in vacanza quest'anno

Se ne parlava come al solito con gli amici dall'anno scorso. Si doveva decidere solo tra due paesi: l'Armenia o la Georgia. Fino a febbraio di quest'anno ne parlavamo, ma poi problemi miei e di altre persone del gruppo ci hanno fatto desistere da questo viaggio.

Come si dice, non tutto il male viene per nuocere sapendo che saremmo stati in uno di quegli Stati proprio questa settimana.

Tags: Off Topic