In questa seconda parte proveremo ad eseguire gli stessi passi eseguiti in precedenza utilizzando “la migrazione automatica dello schema”. Per comodità riporto la classe DbContext ed il semplice Object Model utilizzato per la definizione dello schema del database:
public class OfficeContext : DbContext
{
public OfficeContext()
: base("OfficeDB")
{
}
public DbSet<Employee> Employees { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
static OfficeContext()
{
Database.SetInitializer<OfficeContext>(null);
}
}
public class Employee
{
public int Id { get; set; }
public String Name { get; set; }
public String Surname { get; set; }
public String Role { get; set; }
}
Avendo aggiunto EntityFramework.Migrations in precedenza, per continuare, dobbiamo aprire la classe Configuration.cs all’interno della cartella Migrations ed impostare la proprietà AutomaticMigrationsEnabled a true:
public Configuration()
{
AutomaticMigrationsEnabled = true;
AutomaticMigrationDataLossAllowed = false;
}
Inoltre impostiamo la proprietà
AutomaticMigrationDataLossAllowed=false: in questo modo un’eccezione verrà sollevata nel caso in cui la migrazione dello schema comporti una perdita di dati. Nell’
override del metodo
Seed aggiungiamo del codice per inserire delle righe dopo la generazione\migrazione dello schema:
protected override void Seed(OfficeContext context)
{
context.AddOrUpdate(
new Employee() { Name = "Mario", Surname = "Rossi", Role = "Administrator" },
new Employee() { Name = "Giulio", Surname = "Verdi", Role = "Store Manager" },
new Employee() { Name = "Pietro", Surname = "Libro", Role = "Art Director" }
);
}
A differenza della procedura manuale, digitiamo direttamente il comando
update-database nella console di NuGet, eventualmente utilizzato i parametri –
verbose o
-script rispettivamente per visualizzare o creare un file di
.sql con i comandi generati da VS:
Come per la prima parte, utilizzando ad esempio SQL Management Studio, vediamo che il lavoro “sporco” sia stato eseguito correttamente come ci aspettavamo:
Ora, se volessimo apportare le stesse modifiche allo schema del modello dati, come nel caso del post precedente, dovremmo ritornare “in modalità manuale” (in quanto, in questa modalità non possiamo specificare i valori di default per i nuovi campi o utilizzare codice SQL custom) quindi utilizzando il comando Add-Migration e relativi parametri. Ovviamente abbiamo già discusso su come eseguire questi passaggi e non staremo qui a ripeterli: IMHO la migrazione automatica non mi ha entusiasmato molto a differenza di quella manuale dove è possibile intervenire in diversi punti.
Proviamo ora ad eliminare (o commentare) la proprietà Surname dall’entità Employee:
public class Employee
{
public int Id { get; set; }
public String Name { get; set; }
public String Role { get; set; }
}
Commentiamo il codice presente nel Seed ed eseguiamo il comando update-database:
Entity Framework ci avverte che l’aggiornamento non è stato completato perché potrebbe verificarsi una perdita di dati, ma allo stesso tempo ci suggerisce di utilizzare il parametro –force per forzare l’aggiornamento della base di dati (con conseguente data loss). Ok.
Oltre a commentare il codice (non proprio una best practice) per evitare di aggiungere dati duplicati tramite l’AddOrUpdate del Seed è sufficiente istruire VS con una Func<TEntity,Object> al fine di specificare quali proprietà devono essere considerate per identificare un record come duplicato:
System.Linq.Expressions.Expression<Func<Employee, object>> identify =
n => new { n.Name, n.Role };
context.AddOrUpdate(identify,
new Employee() { Name = "Mario", Role = "Administrator" },
new Employee() { Name = "Giulio", Role = "Store Manager" },
new Employee() { Name = "Pietro", Role = "Art Director" }
);