12. Call the GetContext() method to create the instance of context class in Program.cs. Ideally, when we run the application and instance of context class get created, the database should be ready at local db.
    
    
    
    
    Code
    
    1. using System;
    2. using System.Collections.Generic;
    3. using System.Linq;
    4. using System.Text;
    5. using System.Threading.Tasks;
    7. namespace EmployeeManagement
    8. {
    9. class Program
    10. {
    11. static void Main(string[] args)
    12. {
    13. var context = Initialize.GetContext();
    14. context.EnsureSeedDataForContext();
    15. }
    16. }
    17. }

13. This is a code-first approach for a new database, so the database should be generated if it doesn't exist yet. Let's open our EmployeeManagementContext again to make sure that happens. To the constructor that will be used when requesting an instance from the container through dependency injection, we call EnsureCreated() on the database object. This database is an object is defined on DBContext. If the database already exists, nothing will happen, but if it doesn't, this call ensures it is effectively created.
    
    Context constructor
    
    1. public EmployeeManagementContext(DbContextOptions<EmployeeManagementContext> options) : base (options){
    2. Database.Migrate();
    3. }

14. Run the application. Once the application is run and Program.cs’s main method executes the GetContext() method, let's open that SQL Object Explorer window again. Let's refresh the database list from our MSSQLLocalDB instance. And it looks like our EmployeeManagementDB data is there. Let's have a look at the tables. Apparently, two tables have been created, a Departments and an Employee table, the pluralized names of our entities.
    
    
    

15. The Departments table has a primary key, DepartmentId, a DepartmentName with a maximum length of 50, which cannot be null. If you look at the Department entity, we see that the column definition matches the definition of the fields on our Department entity. Let's have a look at the Employees table. It has a DepartmentId, which is a foreign key, and it has an EmployeeName field, which is required, thus cannot be null, and a maximum length of 50. So that matches our Employee entity. The attributes we applied to the properties on our entity classes were, thus, taken into account. So far, so good. But this is only one way of doing this.
    
    
    

If we work like this, we work by ensuring the database is created by calling Database.EnsureCreated(). But if we do that, well, we're forgetting something. Just as code evolves, a database evolves as well. Let's look into migrations to see how we can improve on what we've done up until now and how we can handle an evolving database.

Code First Migrations in EF Core

Just as our code evolves, so does the database. New tables might be added after a while, existing tables might be dropped or altered. Migrations allow us to provide code to change the database from one version to another. They're an important part of almost all applications, so let's look into it. What we are going to do, we are going to use migrations to create the initial database version, version 1. So, we'll replace what we did in the previous demo by this new and better approach. The reason is that by doing that, we'll have code in place to start from no database at all, rather than having to provide an already existing one. Then, we'll add another migration to migrate to a new version, version 2. To allow for something like this, we'll first need to create an initial snapshot of our database. In the Entity Framework core world, this is achieved with tooling, so we'll have to add these tools first. And these tools are essentially just another set of dependencies that add commands we can execute.

1. Let's add the package Microsoft.EntityFrameworkCore.Tools.
   
   
   

2. So, then we'll have to create that initial snapshot or migration of our database and schema. For that, we have to be able to execute one of the commands we just enabled. And executing those commands, well, you can do that in the package manager console. If you don't currently see that, you can get it via Tools, NuGet Package Manager, Package Manager Console.
   
   
   

3. The command we're looking for is the Add-Migration It expects a name for the migration we're going to add. So, let's say we want to name it EmployeeManagementInitialMigration.
   
   
   

4. It gives us the error that it cannot create the object of type EmployeeManagementContext and asks us to add an implementation of IDesignTimeContextFactory. So, let’s create a new class named DesignTimeContextFactory inheriting from IDesignTimeDbContextFactory of our context class and add te CreateDbContext method which creates optionsBuilder and returns the context class instance with these options as a parameter.
   
   
   
   
   Code
   
   1. using System;
   2. using System.Collections.Generic;
   3. using System.IO;
   4. using System.Linq;
   5. using System.Text;
   6. using System.Threading.Tasks;
   7. using Microsoft.EntityFrameworkCore;
   8. using Microsoft.EntityFrameworkCore.Design;
   9. using Microsoft.Extensions.Configuration;
   11. namespace EmployeeManagement
   12. {
   13. public class DesignTimeDbContextFactory : IDesignTimeDbContextFactory<EmployeeManagementContext>
   14. {
   15. public EmployeeManagementContext CreateDbContext(string[] args)
   16. {
   17. var optionsBuilder = new DbContextOptionsBuilder<EmployeeManagementContext>();
   18. optionsBuilder.UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EmployeeManagementDB;Trusted_Connection=True;");
   20. return new EmployeeManagementContext(optionsBuilder.Options);
   21. }
   22. }
   23. }

5. Now run the Add-Migrationcommand i.e.

Add-Migration EmployeeManagementInitialMigration

If we look at our solution now, we see there's a new Migrations folder. And it contains two files. One, a snapshot of our current context model.

Let's have a look at that.

6. This contains the current model as we defined through our entities, including the annotations we provided. We can find our Department entity and our Employee entity. And at the end of the file, the relation between Department and Employee.
   
   
   

7. The second file we see is the EmployeeManagement InitialMigration. That's the name we just gave to our migration. This contains the code needed by the migration builder to build this version of the database, both Up (from current to the new version) and Down (from this version to the previous version). If we look at Up, we see two CreateTable statements and a CreateIndex statement. That means it's starting from no database at all, and this migration contains the code to build the initial database. And if we look at Down, we see what should happen to end up with an empty database--two DropTable statements.
   
   
   

If new migrations are added, new files like this will be created, and by executing them in order our database can evolve together with our code. By the way, you don't need to run the Add-Migration command to generate these files. We could've written them by hand. And that might still be feasible for one or two or three tables maybe. But it's definitely not something you want to do for a larger database. So, these tools are quite helpful. So far, so good.

8. There's one more thing we have to do. We have to ensure that the migration is effectively applied to our database. And there's another command for that. It's called the update-database command. If we execute this, the migrations will be applied to our current database. Rather than doing it from command, I’ll show you how we can do this from code.
   
   
   

9. Let's open the context again. What we can do is replace Database.EnsureCreated() by Database.Migrate(). This will execute migrations, which, if there's no database yet, will create it. And that's really all we have to do. But as said, we're replacing what we did in the previous clip because, well, most applications do require migrations. And for those, it's a good idea to start from no database at all if you have the chance.
   
   
   
   1. public EmployeeManagementContext(DbContextOptions<EmployeeManagementContext> options) : base (options)
   2. {
   3. Database.Migrate();
   4. }

10. So, what we want to do is remove the current database first. If we don't do that, this call will try and apply the migrations, i.e., create the Departments and Employees tables, and that will fail because they already exist. In the SQL Server Object Explorer, right-click the existing database and delete it.
    
    
    

If you do want to provide an existing database, you can follow the same flow we just did, but delete the first migration file. Generally speaking, though, that's not a good place to be unless your application must start from an existing database. Let's give this a try.

11. Run the application.
    
    
    

12. Let's have a look at our localDB Let's refresh the databases list. Our database was created again, but by working like this instead of how we did it previously, we've ensured our database can migrate from not existing at all to its initial version and upcoming versions after that. A better approach than what we did in the previous sections. Let's have a look at the database itself.
    
    
    

It now contains an additional table--_EFMigrationsHistory. Let's have a look at what's in there. Entity Framework Core uses this table in the database to keep track of which migrations have already been applied to the database.

This ensures that that Database.Migrate() call, or alternatively, the Update-Database call from the command line doesn't try to execute the same migrations over and over again.

13. Let’s continue with adding a new migration. An Employee doesn't seem to have a salary. We may have missed that on purpose because this allows us to look into an additional migration. So, let's add that Salary property.
    
    
    
    
    Code
    
    1. using System;
    2. using System.Collections.Generic;
    3. using System.ComponentModel.DataAnnotations;
    4. using System.ComponentModel.DataAnnotations.Schema;
    5. using System.Linq;
    6. using System.Text;
    7. using System.Threading.Tasks;
    9. namespace EmployeeManagement
    10. {
    11. public class Employee
    12. {
    13. [Key]
    14. [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
    15. public int EmployeeId { get; set; }
    17. [Required]
    18. [MaxLength(50)]
    19. public string EmployeeName { get; set; }
    20. public int DepartmentId { get; set; }
    22. public int Salary { get; set; }
    24. [ForeignKey("DepartmentId")]
    25. public virtual Department Department { get; set; }
    26. }
    27. }

14. Then, let's execute the Add-Migrationcommand again so the file gets generated for us. Let's name this migration EmployeeManagementAddSalaryToEmployee.
    
    
    

Our Migrations folder now includes a new file.

And if looking at this file, we see that the Up method contains the code to add the Salary column, and the Down method contains the code to drop the column again.

15. Let's run the application again.
    
    
    

16. Let's have a quick look at the database. Employees now indeed contain a Salary column.
    
    
    

17. Let's have a look at that EFMigrationHistory table. And, indeed, it also contains the new migration. And that's how we can work with migrations to migrate our database from one version to another. But if we look at the data that's in these tables, we see there's nothing there yet. No Employees, Department. To add data to start with, we should seed the database. Let’s see in the next section how we can do that.
    
    
    

Seeding the Database

We still haven't got data in our database. It would be nice to have some to test with. That principle, providing your database with data to start with, is called seeding the database. It's often used to provide master data.

We saw how we do that in EF 6 versions. Here we’ll discuss another approach to seed the database.

1. We'll write an extension method in our context. So, let's start with that extension method. Let's add a new class, EmployeeManagementContextExtensions. Let's make it static.
   
   
   

2. Let's add one static method to it, EnsureSeedDataForContext. The method has one parameter of type EmployeeManagementContext named context, and it's decorated with this, which tells the compiler it extends EmployeeManagementContext. The first thing we want to do is check if the database already contains our sample data. We want to insert departments and their employees. So, let's check if the Departments table is empty. An employee can't exist without a department, so that's sufficient. If it's not empty, we already have data in there, and we don't want to insert additional data. And, otherwise, we can start adding data. We first create a Department with the name “Technology” and provide three employees (Jack, Kim, Shen) to that department. We do not provide IDs as these are now auto-generated by the database. Then we'll want to add these to the context. For that, we can use Add method or AddRange method if there are multiple departments on the Departments DBSet on our context. And from this moment on, the entities are tracked by the context. But they aren't inserted yet. For that, we must call SaveChanges on the context. Calling SaveChanges on the context will effectively execute the statements on our database.
   
   
   
   
   Code
   
   1. using System;
   2. using System.Collections.Generic;
   3. using System.Linq;
   4. using System.Text;
   5. using System.Threading.Tasks;
   7. namespace EmployeeManagement
   8. {
   9. public static class EmployeeManagementContextExtensions
   10. {
   11. public static void EnsureSeedDataForContext(this EmployeeManagementContext context)
   12. {
   13. if (context.Departments.Any())
   14. {
   15. return;
   16. }
   18. Department department = new Department
   19. {
   20. DepartmentName = "Technology",
   21. Employees = new List<Employee>
   22. {
   23. new Employee() {EmployeeName = "Jack"},
   24. new Employee() {EmployeeName = "Kim"},
   25. new Employee() {EmployeeName = "Shen"}
   26. }
   27. };
   29. context.Departments.Add(department);
   31. Employee employee = new Employee
   32. {
   33. EmployeeName = "Akhil Mittal",
   34. DepartmentId = 1
   35. };
   37. context.Employees.Add(employee);
   38. context.SaveChanges();
   39. }
   40. }
   41. }
   And that's already it for the extension method. Then we need to execute this extension method.

3. Call the extension method EnsureSeedDataForContext() after you create the instance of the context in Program.cs class. Then run the application.
   
   
   
   Code
   
   1. using System;
   2. using System.Collections.Generic;
   3. using System.Linq;
   4. using System.Text;
   5. using System.Threading.Tasks;
   7. namespace EmployeeManagement
   8. {
   9. class Program
   10. {
   11. static void Main(string[] args)
   12. {
   13. var context = Initialize.GetContext();
   14. context.EnsureSeedDataForContext();
   15. }
   16. }
   17. }

4. Let's have a look at our database. And the Departments table contains sample data, and so does the Employees table. And with that, we now know what Entity Framework Core is, its most important concepts, and how to use those.
   
   
   
   
   
   

EF Core Summary

The .NET Core and Entity Framework Core are truly cross-platform, but they're cross-platform on two levels. You can run .NET Core apps using EF Core on any of these platforms, but you can also create, debug, and build them on any one of the platforms as well, and with this cross-platform tool, Visual Studio Code and all of its rich features, plus the fact that it is open source, I've got the ability to do that coding and debugging on any one of the platforms. Visual Studio Code only enhances the flexibility we have for working with .NET Core and Entity Framework Core, but EF Core itself is also flexible. You can also deploy these apps to Docker and run them anywhere that Docker runs. Entity Framework Core is a lightweight, extensible, and cross-platform version of Entity Framework. It's recommended for new applications that don't need the full Entity Framework 6 feature set and for .NET Core applications. We created entity classes first. We can use annotations on those to define things like primary and foreign keys, required fields, and so on. Those are then registered as DBSets on the DBContext. That context represents a session with the database. And it can be used to query and save instances of our entities. From that moment on, we could access our entities through LINQ. There was another important concept we looked into--migrations. Just as our code evolves, so does the database. New tables might be added. After a while, existing tables might be dropped or altered. Migrations allow us to provide code to change the database from one version to another. And, lastly, we investigated an option to seed the database providing it with data to start with. Download the complete free eBook (Diving into Microsoft .NET Entity Framework) on Entity Framework here.