AZ - Il blog di Andrea Zani

Entity Framework. Una tabella due Entity senza discriminazioni

In un blog precedente avevo parlato del Single Table Inheritance. Grazie ad un campo apposito è possibile decidere a quale entity farà parte il record di quella nostra tabella.

Il problema che sto cercando di risolvere in questi giorni si basa sul quesito:

E' possibile dividere una tabella in due entity senza questo campo?

Ma prima che subentri la confusione, il mio obbiettivo non è quello di creare due entity parallele come nel caso di quel blog (TextContents e LinkContents), ma una entity di base da cui deriva un'altra entity. Per esempio, da questa tabella:

*Nome campo*	*Tipo*
Id	int
Title	nvarchar(50)
LongDescriptions	ntext

Vorrei ottenere una struttura come questa (poi spiegherò il perché):

Il problema che mi ero posto è molto semplice: in caso volessi visualizzare tutti i record della tabella in un menu di scelta, la richiesta dei dati presenti in un'unica entity avrebbe richiesto tutti i campi anche quelli ntext (che potrebbero contenere, per assurdo, mega di documenti di testo), come si può evitare questo?

Ah, dimenticavo, visto che questi dati devono attraversare dei layer dell'applicativo, non voglio usare gli anonynous type, altrimenti sarebbe troppo facile scrivere:

var coll=from d in Context.Documents
select new { Id=d.Id, Title=d.Title };
return coll;

Anche se questa soluzione porta l'Entity Framework a inviare la giusta query al database:

SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title]
FROM [dbo].[Descriptions] AS [Extent1]

Una soluzione che mi hanno suggerito è creare una classe che ospiti solo quei dati:

public class Elenco
{
public int Id { get; set; }
public string Title { get; set; }
}

var coll = from c in context.Descriptions
select new Elenco { Id = c.Id, Title = c.Title };
foreach (var item in coll)
{
Response.Write(string.Format(
"{0} {1} <br />",
item.Id,
item.Title
));
}

Può andare. Si potrebbe trovare un'altra soluzione con l'uso delle viste. Creata questa vista:

select Id,Title from Descriptions

Si possono creare due entity distinte all'interno dell'editor di Visual Studio 2008:

Lo schifo è che sono due entity distinte, ma risolvono in parte il problema. Segnalo che, importata questa vista nell'editor, i campi vengono visti entrambi come key. Non è sufficiente modificare le proprietà nell'editor, è necessario aprire il file .edmx con un editor xml e cancellare la doppia key:

Poco sopra nell'xml è possibile vedere com'è importata la vista:

<EntitySet Name="DescriptionsTitles" EntityType="TestEntitiesModel.Store.DescriptionsTitles" store:Type="Views" store:Schema="dbo" store:Name="DescriptionsTitles">
<DefiningQuery>SELECT
[DescriptionsTitles].[Id] AS [Id],
[DescriptionsTitles].[Title] AS [Title]
FROM [dbo].[DescriptionsTitles] AS [DescriptionsTitles]
</DefiningQuery>
</EntitySet>

Questo comporta, alla richiesta dei dati, l'esecuzione di questa query:

SELECT
[Extent1].[Id] AS [Id],
[Extent1].[Title] AS [Title]
FROM (SELECT
[DescriptionsTitles].[Id] AS [Id],
[DescriptionsTitles].[Title] AS [Title]
FROM [dbo].[DescriptionsTitles] AS [DescriptionsTitles]) AS [Extent1]

Alla fine c'è la soluzione compatibile con l'Entity Framework e la mia necessità. Ma si deve mettere mano alla struttura del database. Si deve dividere quella tabella in due, spostando il campo LongDescriptions nella seconda naturalmente collegando il tutto. L'EF non farà una piega e vedrà il tutto in modo corretto e otterrei ciò che voglio.

Posso avere tutto ciò che voglio? No, non è possibile.

Intellisense in Sql Server 2008

C'è una tabella:

L'intellisense c'è?

Che bello. Cancello la tabella. Rifaccio una query e cosa mi compare?

Ma se l'ho cancellata!!!

Il bello avviene anche con tabelle nuove che non vengono viste dall'intellisense del Managment Studio di Sql Server 2008. Lo si deve riavviare per aggiornare il tutto.

O mi è sfuggito qualcosa? La delusione però c'è. Bel bug!!!

Questo problema me l'ha fatto notare un collega, da quando c'è EF, Sql server non lo guardo più :-)

Tags: Database, SQL Server

Entity Framework e più tabelle in una entity

Breve e coinciso. Due tabelle in una sola entity. L'Entity Framework lo permette con pochi passaggi e non in automatico.

Mi servono due tabelle. Eccole:

Tutorials

Nome campo	Tipo e altro
Id	Int, key, Auto increment
Name	nvarchar
Description	Text

Tutorials2

Nome campo	Tipo e altro
Id	Int, key
Name	nvarchar
Description	Text

Ora importiamo le due tabelle nel designer di Visual Studio 2008. Creerà due entity distinte. Non ci servono a nulla. Vanno cancellate. Quindi dalla toolbar, inserire una nuovo oggetto Entity e si mappano all'interno le due tabelle e tutti i campi, naturalmente inserendo nell'editor tante proprietà quante ne servono. Il risultato finale deve essere simile a questo:

Tutto fatto. Ora possiamo farne quello che vogliamo:

using (pubsModel.pubsEntities context = new pubsModel.pubsEntities())
{
    pubsModel.Tutorials obj = new pubsModel.Tutorials();
    obj.Name1 = "A1";
    obj.Name2 = "A2";
    obj.Description1 = "D1";
    obj.Description2 = "D2";
    context.AddToTutorialsSet(obj);
    context.SaveChanges();
}

Un ringraziamento a David che mi ha dato un ottimo suggerimento a riguardo. Ora ho solo un unico dubbio e poi con l'EF spacco tutto: dividere una tabella in due o più entity.

L'Entity Framework e le custom class coinvolte nei where...

Riprendo il solito esempio di entity:

Ipotizzando di voler recuperare tutti gli Articles con un determinato colore si potrebbe essere spinti a scrivere:

var c=Context.Colors.Where(cc=>cc.Id==1).First();
var coll=from ar in Context.Articles.Include("Colors")
where ar.Colors=c
select ar;

Semplicemente, avendo una entity voglio vedere tutte le entity che hanno come property questo oggetto. Eseguita, però, si ottienere questo errore:

Unable to create a constant value of type 'Closure type'. Only primitive types (for instance Int32, String and Guid) are supported in this context.

Questo perché l'EF non permette il confronto tra oggetti complessi. La soluzione è banale, anzi, in qualche caso più semplice (nel caso di web control che ritornano un valore numerico per identificare una scelta di un utente, per sempio da un dropdownlist):

int c=int.Parse(ddl_colors.SelectedValue); // <- prendo il colore selezionato
var coll=from ar in Context.Articles.Include("Colors")
where ar.Colors.Id=c
select ar;

Oppure:

var c=Context.Colors.Where(cc=>cc.Id==1).First();
var coll=from ar in Context.Articles.Include("Colors")
where ar.Colors.Id=c.Id
select ar;

Soluzione semplice, ma è sempre bene saperla.

Entity Framework e l'ereditarietà (Single Table Inheritance)

Visto che in questi gioni sto usando parecchio con l'Entity Framework questa Table Per Hierarchy (Emanuele mi correggerà se, come al solito, sbaglio la nomenclatura), ecco due appunti su come si realizza con l'editor che mette a disposizione Visual Studio 2008.

L'inizio è questa semplice tabella dal nome BaseContents:

Da questa singola tabella è possibile estrarre due entity distinte. Nel mio caso:

TextContents
LinkContents

La prima utilizzata per memorizzare il contenuto reale di un eventuale testo, la seconda per link a risorse esterne. All'interno di questa singola tabella sono contenuti tutti i campi per memorizzare queste informazioni. L'unico campo aggiuntivo, che farà da discriminante, come si vedrà di seguito, è Type.

Creato in Visual Studio 2008 un nuovo oggetto ADO.Net Entity Data Model, e importanto all'interno di questo oggetto la tabella sopra mostrata, si avrà la prima entity creata in automatico dall'ambiente di sviluppo con tutti i campi interessati.

Ora è possibile aggiunere le entity mancanti, TextContents e LinkContents, ereditandole direttamente da questa (è sufficiente cliccare con il tasto destro all'interno dell'editor e selezionare Add -> Entity). Aggiunte le due entity ecco cosa abbiamo in VS 2008:

Ora possiamo spostare le property di nostro interesse nelle sottostanti entity per ottenere questo:

Dalla window Mapping details, mappiamo la tabella e assicurati che tutti i campi interessati siamo mappati correttamente, possiamo inserire la condizione discriminante, in modo che nell'uso di una o dell'altra entity, siano salvati i dati corretti nella tabella. Nulla di difficile, sempre da Mapping details, si aggiunge nelle condition:

In questo caso ho inserito il valore 1 in Type per il TextContents, e 2 per il LinkContents. Sembra tutto fatto, ma ecco l'amara sorpresa che ho trovato compilando il tutto:

Error 1 Error 3032: Problem in Mapping Fragment starting at line 49: Condition member 'BaseContents.Type' with a condition other than 'IsNull=False' is mapped. Either remove the condition on BaseContents.Type or remove it from the mapping.

Scopro che Type crea un problema. Il mio primo tentativo di cancellazione di questa property dall'entity BaseContents mi porta un nuovo errore:

Error 1 Error 3023: Problem in Mapping Fragments starting at lines 48, 54, 59: Column BaseContents.Type has no default value and is not nullable. A column value is required to store entity data.
An Entity with Key (PK) will not round-trip when:
(PK is in 'BaseContents' EntitySet AND Entity is type TestEntitiesModel.BaseContents)

Alla fine scopro la soluzione da un blog di Zeeshan Hirani (che spiega il tutto in modo molto più dettagliato, ma visto che ho scritto fino a qua, non ho voglia di buttare il tutto) che ringrazio perché mi ha fatto trovare immediatamente la soluzione. E' sufficiente modificare la property Abstract dell'Entity BaseContents in true, per eliminare ogni errore.

Ora da codice possiamo inserire e leggere da questa tabella con due entity separate:

using (TestEntitiesModel.TestEntitiesEntities context = new TestEntitiesModel.TestEntitiesEntities())
{
TestEntitiesModel.TextContents c = new TestEntitiesModel.TextContents();
c.Name = "Example 1";
c.Content = "Content text bla bla bla";
context.AddToBaseContents(c);
TestEntitiesModel.LinkContents l = new TestEntitiesModel.LinkContents();
l.Name = "Example 2";
l.Link = "www.aspitalia.com";
l.Impressions = 0;
context.AddToBaseContents(l);
context.SaveChanges();
}

Visualizzando il contenuto della tabella troveremo:

Id	Name	Link	Impressions	Content	Type
1	Example1	null	null	Content text bla bla bla	1
2	Example2	www.aspitalia.com	1	null	2

Per leggere:

using (TestEntitiesModel.TestEntitiesEntities context = new TestEntitiesModel.TestEntitiesEntities())
{
var coll = from c in context.BaseContents.OfType<TestEntitiesModel.TextContents>()
orderby c.Content ascending
select c;
foreach (var item in coll)
{
Response.Write(string.Format("{0} {1} {2}<br />",
item.Id,item.Name,item.Content));
}
}

Questa volta per specificare l'entity da leggere, dobbiamo utilizzare l'OfType come da esempio. Se volessimo richiedere l'entity LinkContents, avremmo duvuto scrivere:

var coll = from c in context.BaseContents.OfType<TestEntitiesModel.LinkContents>()

Oltre al Table Per Hierarchy (Single Table Inheritance) l'EntityFramework mette a disposizione altri due tipi di inheritance:

Table Per Type
Table Per Concrete Class

Ma le cosa iniziano a complicarsi un po' con l'editor di VS2008.

Tags: Visual Studio

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.