Entity Framework 6

EF 6.1 : What’s new (3)

Pietro Libro — Thu, 27 Mar 2014 10:04:00 GMT

Supporto a “.ToString()” e “String.Concat()”, un esempio: var queryConcat = from c in db.Vehicles where string.Concat(c.EngineSize, c.HP).Equals("1600110") select c; var queryToString = from c in db.Vehicles where c.HP.ToString().Equals("110") select c; Abbiamo due Query LINQ che filtrano i dati in base a condizioni su stringhe, la prima “tira fuori” tutti i veicoli dove la concatenazione dei valori delle proprietà “EngineSize” e “HP” è uguale a “1600110”, mentre la seconda esegue un filtro su di un valore intero convertio in stringa. Se proviamo ad eseguire il codice in un ambiente con EF 6.0 otteniamo un’eccezione a runtime in tutti e due i casi: Con EF 6.1 le query sono eseguite correttamente: Cosa succede dietro le quinte: SELECT [GroupBy1].[A1] AS [C1] FROM ( SELECT COUNT(1) AS [A1] FROM [DomusDotNet].[Vehicles] AS [Extent1] WHERE N'1600110' = (CASE WHEN ([Extent1].[EngineSize] IS NULL) THEN N'' ELSE [Extent1].[EngineSize] END + CAST( [Extent1].[HP] AS nvarchar(max))) ) AS [GroupBy1] SELECT [GroupBy1].[A1] AS [C1] FROM ( SELECT COUNT(1) AS [A1] FROM [DomusDotNet].[Vehicles] AS [Extent1] WHERE N'110' = CAST( [Extent1].[HP] AS nvarchar(max)) ) AS [GroupBy1] Da analizzare il funzionamento di “String.Concat(…)” con SQL Server 2012 per verificare la conversione in SQL con la funzione “nativa SQL” “Concat”.

EF 6.1 : What’s new (2)

Pietro Libro — Thu, 20 Mar 2014 17:49:00 GMT

Altra feature introdotta, l’attributo “IndexAttribute” che ci permette di definire un indice su una o piu’ colonne. Ad esempio, per creare un indice (di nome “IX_FreeDailyKm”) sulla proprietà “FreeDailyKm” del nostro modello, scriviamo: [Index("IX_FreeDailyKm_Clustered", IsUnique = false, IsClustered = false)] public int FreeDailyKm { get; set; } Mentre per creare un indice che insiste su due proprietà, è sufficiente utilizzare lo stesso nome come da esempio: [Index("IX_Engine", 2)] public string EngineSize { get; set; } [Index("IX_Engine", 1)] public int HP { get; set; } Utilizzando EF migrations per aggiornare il database, avremmo: CreateIndex("DomusDotNet.Vehicles", "FreeDailyKm", name: "IX_FreeDailyKm_Clustered"); CreateIndex("DomusDotNet.Vehicles", new[] { "HP", "EngineSize" }, name: "IX_Engine"); Quindi, a livello di database:

EF 6.1 : What’s new (1)

Pietro Libro — Thu, 20 Mar 2014 12:42:00 GMT

Da qualche giorno è stata rilasciata in RTM la versione 6.1.0 di Entity Framework. Una delle novità piu’ interessanti è sicuramente la possibilità di utilizzare l’approcio Code First partendo da un database esistente (potrebbe sembrare strano, ma se pensiamo ad un nuovo sviluppo potrebbe non esserlo). I “ferri” da utilizzare sono ovviamente EF 6.0.1 e la nuova versione di EF Tools, “scaricabile” per VS 2012 e VS 2013 seguendo questo link. Per un semplice test, apriamo VS 2013 (o 2012), magari creando un semplice progetto “Console” al quale aggiungiamo tramite NuGet i riferimenti a EF 6.0.1. Poi tasto destro sul progetto e “Add New Item”, e scegliamo “ADO.NET Entity Data model”: Il testo di “Name” infuenzerà il nome della classe “DbContext” generata. Dalla scheramata successiva (“Entity Data Model Wizard”) scegliamo “Code First model from Database”: Nella schermata successiva del Wizard verrà chiesta la connessione dati da utilizzare (eventualmente ne creiamo una nuova), nel mio caso, per i test ho utilizzato un DB di un evento “DomusDotNet”. L’ultimo passo è la scelta degli oggetti da “importare”: Dopo aver premuto “Finish” e qualche secondo di pazienza, VS aggiungerà all’alberatura del progetto, tutte le classi necessarie, una “buildata” per verificare che sia tutto a posto , e qualche riga di codice per verificare l’estrapolazione dati : using (CarRental db = new CarRental()) { System.Console.WriteLine("There are {0} cars.", db.Cars.Count()); System.Console.ReadKey(); }

Dynamic Data Provider per EF6 released

Pietro Libro — Mon, 03 Mar 2014 10:06:00 GMT

Sono stati rilasciati in RTM, ASP.NET Dynamic Data e EntityDataSource per EntityFrameowrk 6. Per provare la nuova versione di Dynamic Data è sufficiente creare un nuovo progetto di tipo “ASP.NET Dynamic Data Entities Web Application”, ed installare tramite NuGet il package Microsoft.AspNet.DynamicData.EFProvider: Eventualmente forziamo la scrittura dei Template (“A” per sovrascrivere tutto): Aggiungiamo in modalità Code First una semplice classe Book e relativo DbContext: public class Book { public int Id { get; set; } public string Title { get; set; } public string Authors { get; set; } public int Pages { get; set; } } public class Db : DbContext { public DbSet<Book> Books { get; set; } protected override void OnModelCreating(DbModelBuilder modelBuilder) { base.OnModelCreating(modelBuilder); } } Nel Global.asax registriamo il nostro DbContext: DefaultModel.RegisterContext( new Microsoft.AspNet.DynamicData.ModelProviders.EFDataModelProvider(() => new Db()), new ContextConfiguration { ScaffoldAllTables = true }); F5, per vedere in azione il nostro Data Site: Discorso simile per l’utilizzo dell’EntityDataSource control.

ASP.NET Dynamic Data provider (preview) per EF6

Pietro Libro — Fri, 31 Jan 2014 10:23:00 GMT

Rilasciato un aggiornamento per ASP.NET DynamicData e DataSourceControl per Entity Framework 6. Tutti i dettagli del caso sul blog originale.

EF : Relazione one-to-many Table-View

Pietro Libro — Thu, 19 Dec 2013 16:55:00 GMT

Immaginiamo di avere un database SQL Server esistente, e vogliamo utilizzare Entity Framework Code First per mappare il modello dati. Supponendo di avere due tabelle “Items” e “Categories” in relazione come da Database Diagram seguente: Ed una “Vista” SQL Server definita come segue: CREATE VIEW [dbo].[VCategories] AS SELECT Id, Name FROM Categories WHERE (Deleted = 0) Aggiungiamo due classi C# definite in questo modo: public class Category { public int Id { get; set; } public string Description { get; set; } } public class Item { public int Id { get; set; } public string Code { get; set; } public string Description { get; set; } public int CategoryId { get; set; } public Category Category { get; set; } } che mappiamo tramite OnModelCreating (nella classe derivata da DbContext) come segue : protected override void OnModelCreating(DbModelBuilder modelBuilder) { modelBuilder.Entity<Category>().ToTable("VCategories") .Property(c => c.Description).HasColumnName("Name"); modelBuilder.Entity<Item>().ToTable("Items"); modelBuilder.Entity<Item>().HasRequired(x => x.Category) .WithMany().HasForeignKey(o => o.CategoryId); } Per verificare il funzionamento del mapping possiamo scrivere del codice tipo: Item item = null; using (Db db = new Db()) { Console.WriteLine("Items count : {0}", db.Items.Count()); Category category = (from c in db.Categories where c.Id == 1 select c) .FirstOrDefault(); item = new Item() { Category = category, CategoryId = category.Id, Code = "Code #1", Description = "Description #1", }; db.Items.Add(item); db.SaveChanges(); Console.WriteLine("Items count : {0}", db.Items.Count()); } using (Db db = new Db()) { ////Edit item.Description = "New Description #1."; db.Entry<Item>(item).State = System.Data.Entity.EntityState.Modified; db.SaveChanges(); Console.WriteLine("Items count : {0}", db.Items.Count()); } using (Db db = new Db()) { ////Delete. db.Entry<Item>(item).State = System.Data.Entity.EntityState.Deleted; db.SaveChanges(); Console.WriteLine("Items count : {0}", db.Items.Count()); }

EF6 RTM Available

Pietro Libro — Thu, 17 Oct 2013 16:25:00 GMT

Con il rilascio di VS 2013, puntuale anche il rilascio in RTM di Entity Framework 6, tutti i dettagli direttamente sul blog di ADO.NET.

EF 6 : Logging & Interception

Pietro Libro — Wed, 04 Sep 2013 15:15:00 GMT

Una delle nuove feature introdotte nella versione 6 di Entity Framework (attualmente in RC) è il supporto al logging dell’SQL generato dal runtime di EF6. A tal fine è sufficiente passare un opportuno delegate alla proporietà Log esposta da DbContext.Database. Per gli esempi riprendiamo lo scenario del post precedente. Supponiamo di avere il seguente codice: using (CarContext db = new CarContext()) { System.Console.WriteLine("Cars in database : {0}", db.Cars.Count()); ////Add a new car. Car car = new Car() { Brand = "Alfa Romeo", Model = "Giulietta" }; db.Cars.Add(car); db.SaveChanges(); System.Console.WriteLine("Cars in database : {0}", db.Cars.Count()); } Che banalmente visualizza il numero di auto (Cars) presenti nel repository, ne aggiunge una e riesegue la conta delle auto registrate. Se volessimo analizzare l’SQL generato un ottimo strumento è sicuramete il SQL Profiler di SQL Server (che non dovrebbe mai mancare quando si lavora con un ORM ), ma se utilizziamo EF6, ed il nostro obiettivo è semplicemente “scoprire\loggare” l’SQL generato da EF, possiamo modificare il codice precedente aggiungendo dopo la definizione del DbContext, la riga seguente: db.Database.Log = Console.Write; Dove la proprietà Log è cosi’ definita: public Action<string> Log { get; set; } Eseguendo il codice della nostra applicazione dovremmo ottenere una “Console” simile alla seguente: Di default il log è molto chiaro in quanto ci restituisce il testo SQL del comando, quando è stato eseguito, il tempo impiegato, il tipo di risultato, gli eventuali parametri ed il tipo corrispondente. Possiamo ovviamente cambiare il contenuto e la formattazione del log secondo le nostre esigenze (e non solo) come vedremo piu’ avanti. Per come è definita la proprietà Log, qualsiasi funzione che accetta una stringa puo’ essere utilizzata per scrivere il nostro log. Quindi potremmo utilizzare un metodo tipo il seguente: public static void Log(string sql) { Console.WriteLine("------------------------------------"); Console.WriteLine("SQL LOG: {0} ", sql); Console.WriteLine("------------------------------------"); } oppure: System.IO.StreamWriter streamWriter = new System.IO.StreamWriter (fileStream, System.Text.ASCIIEncoding.ASCII ); db.Database.Log = sql => streamWriter.Write(sql); Per scrivere il log direttamente su file. Il concetto dovrebbe essere abbastanza chiaro. Vediamo come personalizzare la formattazione del log. Database.Log non fa altro che utilizzare un ogetto DatabaseLogFormatter che a sua volta implementa le interfacce IDbCommandInterceptor e IDbInterceptor che sono rispettivamente l’interfaccia che permette di registrare un oggetto che possa ricevere notifiche da parte di Entity Framework quando un comando viene eseguito e l’interfaccia base per tutte le interfacce che permettono di fornire un Interception Point per differenti tipi di operazione. Quindi, per creare il nostro “Formattatore Custom” non ci resta che ereditare dalla classe DatabaseLogFormatter ed eseguire l’override dei metodi che ci interessano, come nel caso seguente: public class CustomLogFormatter : DatabaseLogFormatter { public CustomLogFormatter(DbContext context, Action<string> writeAction) : base(context, writeAction) { } public override void LogCommand<TResult>( DbCommand command, DbCommandInterceptionContext<TResult> interceptionContext) { Write(string.Format("{0}{1}", "===============================================", Environment.NewLine)); Write(string.Format( "Context{2}{0}{2}Command{2}{1}{2}", Context.GetType().Name, command.CommandText.Replace(Environment.NewLine, ""), Environment.NewLine)); Write(string.Format("{0}{1}", "===============================================", Environment.NewLine)); } } Dove, l’override del metodo LogCommand esegue la formattazione del comando prima che questo sia eseguito da Entity Framework. LogCommand a sua volta chiama eventualmente il metodo LogParameter per ogni parametro del comando, è necessario eseguire l’override di LogParameter per “customizzare” la formattazione del log dei paramateri. Infine, se vogliamo cambiare la formattazione del risultato, è necessario effettuare l’override di LogResult. Per interrompere l’esecuzione del comando, possiamo utilizzare il metodo : interceptionContext.SuppressExecution() Nel corpo dell’override di LogCommand. Per vedere in “funzione” il nostro “Formatter” è sufficiente registrare l’istanza di CustomLogFormatter tramite una classe derivata da DbConfiguration presente nello stesso assembly che contiene la definizione del DbContext: public class MyDbConfiguration : DbConfiguration { public MyDbConfiguration() { SetDatabaseLogFormatter( (context, writeAction) => new CustomLogFormatter(context, writeAction)); } } Eseguendo, otteniamo il “nostro” log: Per approfondimenti: Entity Framework Codeplex One Unicorn: EF6 SQL Logging

Disponibile EF 6 RC

Pietro Libro — Thu, 22 Aug 2013 09:25:00 GMT

Rilasciata la RC di Entity Framework 6, tutti i dettagli e le novità rispetto alla Beta 1, qui.

EF6 (beta) : Multiple Contexts per Database, Multi-Tenant Migrations

Pietro Libro — Mon, 19 Aug 2013 09:38:00 GMT

Una delle novità introdotte con EF6 è la possibilità di gestire molteplici modelli per singola istanza di database, che non vuol dire usare lo stesso contesto piu’ volte nello stesso database, ma poter utilizzare Entity Framework Migrations e relativa Migration History Table per gestire la migrazione di due o piu’ modelli per singolo database fisico. Specifichiamo questa feature come Multi-Tenant Migrations. Come esempio, supponiamo di avere due classi Bus e Car facenti parte dello stesso Domain di una nostra applicazione, ma interessate da due DbContext diversi, rispettivamente BusContext e CarContext, come da Class Diagram seguente: Provando ad abilitare EF Migrations per il progetto corrente, essendo presenti due DbContext, il “Package Manager Console” risponderebbe restituendo l’errore seguente: Vediamo come utilizzare Multi-Tenant Migrations: iniziamo ad utilizzare la prima delle novità di EF6 (migrations), l’opzione “-MigrationDirectory” che ci permette di specificare, insieme all’opzione “-ContextTypeName” che rispettivamente indicano dove far risiedere i piani di migrazione e quale DbContext considerare. Il comando completo da utilizzare diventa quindi: PM>Enable-Migrations -MigrationsDirectory BusDbContextMigration -ContextTypeName MultiTenantMigration.BusContext Questa volta tutto fila liscio, ottenendo un messaggio di questo tipo: Il “Solution Explorer” dovrebbe apparire simile alla figura seguente: Visualizziamo il codice della classe Configuration.cs e modifichiamolo opportunatamente impostando la proprietà ContextKey che altro non è una nuova proprietà di configurazione per EF6 Migrations che aggiunge nella “_MigrationHistory Table” una nuova colonna che rende possibile la funzionalità “Multi-Tenant”:public Configuration() { ContextKey = "BusContextKey"; AutomaticMigrationsEnabled = false; MigrationsDirectory = @"BusDbContextMigration"; } Come prima, eseguiamo le operazioni precedenti per abilitare la migrazione anche per il DbContext “CarContext” ottenendo un “Solution Explorer” simile al seguente: E per Configuration.cs:public Configuration() { ContextKey = "CarContext"; AutomaticMigrationsEnabled = false; MigrationsDirectory = @"CarDbContextMigration"; } Aggiungiamo i corrispettivi piani di migrazione: PM> Add-Migration CarDbMigration -ConfigurationTypeName MultiTenantMigration.CarDbContextMigration.Configuration Scaffolding migration 'CarDbMigration' PM> Add-Migration BusDbMigration -ConfigurationTypeName MultiTenantMigration.BusDbContextMigration.Configuration Scaffolding migration 'BusDbMigration' Procediamo con l’aggiornamento del database (ricordiamo essere lo stesso per i due DbContext). Procediamo con CarDbContext: PM> Update-Database -ConfigurationTypeName MultiTenantMigration.CarDbContextMigration.Configuration Specify the '-Verbose' flag to view the SQL statements being applied to the target database. Applying explicit migrations: [201308141834283_CarDbMigration]. Applying explicit migration: 201308141834283_CarDbMigration. Running Seed method. Il messaggio indica che l’aggiornamento è stato completato con successo. Passiamo ora a BusDbContext: PM> Update-Database -ConfigurationTypeName MultiTenantMigration.BusDbContextMigration.Configuration Specify the '-Verbose' flag to view the SQL statements being applied to the target database. Applying explicit migrations: [201308141835410_BusDbMigration]. Applying explicit migration: 201308141835410_BusDbMigration.Running Seed method. A livello database: In dettaglio, la tabella “MigrationHistory” è popolata con le seguenti righe (da notare la colonna ContextKey): A questo punto, tutte le successive modifiche al modello, ed i relativi piani di migrazione dovrebbero essere applicati con successo.