EntityFramework

EF 5 - IS NULL <> = NULL

Roberto Sarati — Fri, 17 May 2013 22:33:13 GMT

EF 5 aggiunge una importante opzione di configurazione riguardante la "traduzione" delle lambda con parametri NULL: UseCSharpNullComparisonBehavior.
Se impostata a true, il comportamento è simile al comportamento che noi Dev siamo abituati con il valore null di C#. Ma andiamo con ordine:

Tabella:
Id    Name
1    Uno
2    NULL
3    NULL
4    due
5    tre

Codice:

result = db.NullableTables.Where(e => e.Name == null).Count();
Console.WriteLine("Entries where Name=null: {0}", result);

result = db.NullableTables.Where(e => e.Name != null).Count();
Console.WriteLine("Entries where Name!=null: {0}", result);

string name = null;
result = db.NullableTables.Where(e => e.Name == name).Count();
Console.WriteLine("Entries where Name==name & name=null: {0}", result);

Risultato standard:
"Entries where Name=null: 2" //corretto
"Entries where Name!=null: 3" //corretto
"Entries where Name=name & name=null: 0" //wrong?

Il problema dell'ultimo risultato riguarda il metodo utilizzato da EF per convertire la lamba expression "e=>e.Name=name" in TSQL: "Where Name=@p1, @p1=null". In SQL =NULL è sempre false, al contrario del primo esempio dove EF converte la lambda in "where Name IS NULL".

Come possiamo rendere la conversione più C# friendly? con la seguente istruzione (messa nel costruttore del nostro DbContext):
((IObjectContextAdapter)this).ObjectContext.ContextOptions.UseCSharpNullComparisonBehavior = true;

In questo caso, rieseguendo il codice precedente, otterremo il seguente risultato:
"Entries where Name=null: 2" //corretto
"Entries where Name!=null: 3" //corretto
"Entries where Name=name & name=null: 2" //corretto?

Da notare come questa opzione sia disabilitata di default(causa compatibilità).

EF CodeFirst Load data

Roberto Sarati — Wed, 21 Mar 2012 13:07:43 GMT

Capita, soprattutto nel metodo Seed del IDatabaseInitializer<CTX> o nel nuovo DbMigrationsConfigurations<CTX>, di caricare una certa quantità di dati passando dal DbContext (nel mio caso da una piccola applicazione che parsa alcuni file).

Se questa quantità di dati è cospiqua (10000 oggetti), ci si potrebbe ritrovare a perdere un po' di tempo (2 minuti) aspettando che vengano aggiunti al contesto tutti i dati (non sto parlando del tempo di salvataggio, ma di aggiunta al contesto).
Ciò è dovuto al fatto che ogni chiamata al metodo DbSet<Entity>.Add(new object()) chiama implicitamente ObjectContext.DetectChanges().

Per evitare questo, basta impostare:

Context.Configuration.AutoDetectChangesEnabled = false;

Attenzione tuttavia all'uso: "these options are advanced and can potentially introduce subtle bugs into your application if not used correctly" MSDN

[LightSwitch] Utilizzare l'ObjectContext ApplicationData da WCF Ria Service

Roberto Sarati — Wed, 30 Nov 2011 00:20:38 GMT

LightSwitch permette di creare/gestire un database al suo interno senza utilizzare strumenti esterni. Questo DB è chiamato ApplicationData e verrà generato in produzione, in fase di deploy, utilizzando una connection string impostata tramite widzard.

Cosa avviene in pratica:

- La connessione viene memorizzata, sempre con lo stesso nome "_IntrinsicData", all'interno del web.config deployato.
- l'ObjectContext di EF viene autogenerato nel file ServerGenerated\GeneratedArtifacts\ApplicationData.cs

Per utilizzare l'ObjectContext in un WCF Ria Service quindi basta:
- Aggiungere il file al progetto WCF Service (As Link dato che verrà rigenerato)
- Recuperare l'ObjectContext nel seguente modo:

EntityConnectionStringBuilder builder = new EntityConnectionStringBuilder();
builder.Metadata =
  "res://*/ApplicationData.csdl|res://*/ApplicationData.ssdl|res://*/ApplicationData.msl";
builder.Provider = "System.Data.SqlClient";
builder.ProviderConnectionString =
  WebConfigurationManager.ConnectionStrings["_IntrinsicData"].ConnectionString;
var context = new ApplicationDataObjectContext(builder.ConnectionString);

In questo modo è possibile:
- eseguire query complesse sul nostro db applicativo (quelle supportate dal provider di EF)
- sopperire alle "mancanze espressive" delle query linq generate in LightSwitch e poter utilizzare entità custom definite nella nostra libreria (per esempio a fine reportistici)