Entity Framework Code First And Migrations: Part Two

public TechnetModello() : base("name=TechnetModello")  
{ } 

<connectionStrings>  
<add name="TechnetModello" connectionString="data source=(LocalDb)\v11.0;initial catalog=ArticoloEF02.TechnetModello;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />  
</connectionStrings>

<connectionStrings>  
<add name="TechnetModello" connectionString="data source=(LocalDb)\v11.0;initial catalog=TECHNET;integrated security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />  
</connectionStrings>

Enable-Migrations

Add-Migration InitialCreate –IgnoreChanges 

public class Articoli   
{  
    public string Codice   
  {  
        get;  
        set;  
    }  
    public string Descrizione   
    {  
        get;  
        set;  
    }  
    public string CodFamiglia   
    {  
        get;  
        set;  
    }  
}

public class Articoli  
{  
    [Key]  
    [StringLength(15)]  
    [Required]  
    public string Codice   
    {  
        get;  
        set;  
    }  
    [StringLength(50)]  
    public string Descrizione   
    {  
        get;  
        set;  
    }  
    [StringLength(6)]  
    public string CodFamiglia   
    {  
        get;  
        set;  
    }  
}

public class Famiglie   
{  
    [Key]  
    [StringLength(6)]  
    [Required]  
    public string CodFamiglia   
    {  
        get;  
        set;  
    }  
    [StringLength(35)]  
    public string Descrizione   
    {  
        get;  
        set;  
    }  
}

TechnetModello class

The change is made as follows:

public class TechnetModello: DbContext   
{  
    public TechnetModello(): base("name=TechnetModello") {}  
    public virtual DbSet < Articoli > Articoli   
    {  
        get;  
        set;  
    }  
    public virtual DbSet < Famiglie > Famiglie   
    {  
        get;  
        set;  
    }  
}

Second migration

With the new model, ready for use, we can now proceed with the publication of the second migration, this time, with the task of creating the tables in the database.

From the Package Manager Console, we perform the instruction given below:

Add-Migration Tabelle_di_base 

We perform as follows:

Update-Database 

By connecting to the instance of LocalDB, we will see how our tables have been added, in which the final character class name in English was added designates the plural.

This peculiarity, a bit annoying in our language, can be circumvented by a special DataAnnotation, which we will analyze in the context of the upcoming migration.

Initial data in the migration context

It may happen that, after the release of the model updates, you want to provide the preset table data (think, for example, a ministerial table, to be provided as they are and above all ready for the operation). The migrations allow us to distribute the precompiled data, exploiting the Seed () method, which is located in Configuration.cs files. This method is executed subsequent to the migration and is suitable to perform the various operations on the database.

Following our example, we will want to migrate our application people table's Articles and Families with some data, which will be used for the testing.

The Seed method will thus become as shown below:

protected override void Seed(ArticoloEF02.TechnetModello context)   
{  
    context.Articoli.AddOrUpdate(new Articoli   
    {  
        Codice = "Test001", Descrizione = "Articolo di Test 001", CodFamiglia = "F01"  
    }, new Articoli {  
        Codice = "Test002", Descrizione = "Articolo di Test 002", CodFamiglia = "F01"  
    }, new Articoli {  
        Codice = "Test003", Descrizione = "Articolo di Test 003", CodFamiglia = "F03"  
    }, new Articoli {  
        Codice = "Test004", Descrizione = "Articolo di Test 004", CodFamiglia = "F02"  
    }, new Articoli {  
        Codice = "Test005", Descrizione = "Articolo di Test 005", CodFamiglia = "F02"  
    }, new Articoli {  
        Codice = "Test006", Descrizione = "Articolo di Test 006", CodFamiglia = "F01"  
    });  
    context.Famiglie.AddOrUpdate(new Famiglie  
    {  
        CodFamiglia = "F01", Descrizione = "Prodotti Finiti"  
    }, new Famiglie {  
        CodFamiglia = "F02", Descrizione = "Semilavorati"  
    }, new Famiglie {  
        CodFamiglia = "F03", Descrizione = "Materie Prime"  
    });  
}

Notice how it uses, as a parameter, a context variable TechnetModello type: This will then allow you to refer directly to our data entities, calling on the classes representing the tables. These methods allow you to change the underlying data. In our case, we add six items and three families.

We can now use the command again, shown below:

Update-Database

There are pending migrations, but at the end of this command, Seed () method will always be executed. Therefore, going back to query our database and ask a simple SELECT from the tables created, we get the following result:

Data access

In this section, we will see some simple examples to make access to the data in the context of selecting insert, update, and delete.

For all these cases, it is necessary to have a data context properly initialized. In our case, this is achieved with the simple definition of a new reference to a variable, which belongs to the class that extends DbContext, namely:

TechnetModello db = new TechnetModello(); 

More generally, if we want to initialize a data context and delegate the task of having this connection upon completion of the operations you want, we can use the using clause, as shown below:

using(TechnetModello db = new TechnetModello())  
{  
    // TO DO: operazioni di lettura/scrittura    
}

Data querying

Data querying refers to a simple routine to make the cyclic reading.

As it appears to be clear from the premises, our tables can be thought of as the lists belonging to a given type, which is precompiled (existing data in the table) and editable.

Consequently, once it initialized the data context, the entity items can be scrolled as a normal custom.

using(TechnetModello db = new TechnetModello())  
{  
    foreach(Articoli a in db.Articoli)   
    {  
        MessageBox.Show(a.Codice + " " + a.Descrizione);  
    }  
}

The snippet above initializes the data context on the db variable. Within a for / each loop, we read the individual entities of the type contained in Articles db.Articoli list, on the code description screen. In these cases, the LINQ syntax is obviously very useful to run the queries or to target the selections.

For example, suppose you want to extract a type of Articles variable representing the first occurrence of the items that the family code of F02 has.

With LINQ syntax, we can write concisely the following snippet:

using(TechnetModello db = new TechnetModello())   
{  
    Articoli a = db.Articoli.Where((x) => x.CodFamiglia == "F02").FirstOrDefault();  
    if (a != null) MessageBox.Show(a.Codice);  
}

New record insert

The operations of insertion pass - of course - for the referencing of a type compatible with that of the variable list, append it to the latter, once the properties are enhanced. A new type of Articles variable can be declared as follows:

Articoli a = new Articoli() { Codice = "PROVA", Descrizione = "Articolo inserito da codice", CodFamiglia = "" };

Obviously, the DbSet items have an Add () method, which will allow us to pass this variable to the set to add to it. No other controls, however, will expose us to the risk that entered the duplicate keys in the database. Therefore, it becomes necessary, before inserting our variable, to check if its key elements are not already specified.

With LINQ, it all becomes very simple, as follows:

Articoli a = new Articoli()  
{  
    Codice = "PROVA", Descrizione = "Articolo inserito da codice", CodFamiglia = ""  
};  
if (db.Articoli.Find(a.Codice) != null) MessageBox.Show("Articolo già presente su tabella Articoli");  
else db.Articoli.Add(a);

We defined our type of Articles variable. Let's run the Find () method on the table DbSet representative, looking at any occurrences of a.Codice, or the primary key of the table. In case you find an existing item, we will issue a notice of an inability to proceed, but not to add the element.

However, in the data modification operations, simply do not act on the entities: it is necessary to consolidate the changes or to inform the Entity Framework required to save the changes that occurred during the use of DbSet. DbContext has a method called SaveChanges (), which precisely performs this consolidation. It also has a property to be used for control purposes with the changes that occurred on the database. You can then, before performing the same routine, introduce a preliminary check to make sure that the procedure, shown below, is actually necessary:

using(TechnetModello db = new TechnetModello())  
{  
    Articoli a = new Articoli()   
    {  
        Codice = "PROVA", Descrizione = "Articolo inserito da codice", CodFamiglia = ""  
    };  
    if (db.Articoli.Find(a.Codice) != null) MessageBox.Show("Articolo già presente su tabella Articoli");  
    else db.Articoli.Add(a);  
    if (db.ChangeTracker.HasChanges()) db.SaveChanges();  
}

Since the snippet shown above may not produce variations in DbSet (in case of which a duplicate key is detected), we use the ChangeTracker properties and its HasChanges method to check whether the modifications on DbContext are available or not. If so, you run the SaveChanges method and consolidate current data.

Updating existent records

At this point, the update operations and delete data become obvious. Suppose we want to change the newly inserted record or having a key field code = TEST.

The first thing to do is to locate the DbSet items and then - if it is; we can change its properties. This operation will update at the same time the ChangeTracker, by which we will determine whether to perform a data consolidation or not.

Very simply, the code will be as follows:

using(TechnetModello db = new TechnetModello())  
{  
    Articoli a = db.Articoli.Find("PROVA");  
    if (a != null)   
    {  
        a.CodFamiglia = "F03";  
    }  
    if (db.ChangeTracker.HasChanges()) db.SaveChanges();  
}

In this case, we want to update the single record, the Family Code, bringing it to F03. Note, that it is sufficient to have the corresponding property setting when you have found the record. This can of course be performed for all the desired items. The SaveChanges () method must be called only once, in the end for the processing.

Record deletion

Even deleting a record is simple: it is to remove a particular item from DbSet items and re-consolidate the change

In the following snippet, the research article has a key field code = TEST is performed and its subsequent removal, if found:

using(TechnetModello db = new TechnetModello())  
{    
    Articoli a = db.Articoli.Find("PROVA");    
    if (a != null) db.Articoli.Remove(a);    
    if (db.ChangeTracker.HasChanges()) db.SaveChanges();    
}

Table name modification

As a final aspect of this article, we will see how to change the names of the physical tables through Data Annotations.

Additional considerations about it will be made in the future; when we will discuss more closely the so-called Fluent API.

We have seen how, by default, the Entity Framework generates tables giving them a character and queue name, which defines the plural in English. In Italian, we have already declined the names in the plural class, we want to avoid the tables that are created with a different nomenclature than you expect. Enough will precede the declaration of the classes and the items in the Families Data Annotation of the Table, indicating the name that the tables will have to hire.

The TechnetModello files therefore will appear, as shown below:

using System;  
using System.ComponentModel.DataAnnotations;  
using System.ComponentModel.DataAnnotations.Schema;  
using System.Data.Entity;  
using System.Linq;  
  
public class TechnetModello: DbContext {  
    public TechnetModello(): base("name=TechnetModello") {}  
    public virtual DbSet < Articoli > Articoli {  
        get;  
        set;  
    }  
    public virtual DbSet < Famiglie > Famiglie {  
        get;  
        set;  
    }  
}  
  
[Table("Articoli")]  
public class Articoli {  
    [Key]  
    [StringLength(15)]  
    [Required]  
    public string Codice {  
        get;  
        set;  
    }  
  
    [StringLength(50)]  
    public string Descrizione {  
        get;  
        set;  
    }  
  
    [StringLength(6)]  
    public string CodFamiglia {  
        get;  
        set;  
    }  
}  
  
[Table("Famiglie")]  
public class Famiglie {  
    [Key]  
    [StringLength(6)]  
    [Required]  
    public string CodFamiglia {  
        get;  
        set;  
    }  
  
    [StringLength(35)]  
    public string Descrizione {  
        get;  
        set;  
    }  
}

At this point, we can generate a new migration, shown below:

Add-Migration NomiTabelle 

and subsequently, run it

Update-Database

After the migration, we are going to query the database TECHNET and we will see how the name of the tables has changed, reflecting more hours than desired.

Conclusion

Here we've briefly outlined the methodologies concerning the Code-First paradigm of Entity Framework, showing some examples of the use of the created entities, and focusing on data modeling possibilities underlying the context. We recommend the reader to become familiar with these concepts, together with those of the previous article, and waiting to continue this overview with the upcoming events of the series.

Other languages

The present article is available in the following localizations:

• [it-IT] Introduzione ad Entity Framework con C#, parte II: Code-First e Migrazioni (it-IT)
• Entity Framework Introduction with C#, part II - Code-First and Migrations