In this recipe, we start by separating the application into a user interface (UI) layer, a data access layer, and a business logic layer. This will allow us to keep our objects separated from database-specific implementations. The objects and the implementation of the database context will use a layered approach so we can add testing to the application. The following table shows the various projects, and their purpose, available for code-first approach:
We will be using the NuGet Package Manager to install the Entity Framework Core 1 package, Microsoft.EntityFrameworkCore. We will also be using a SQL Server database for storing the data, so we will also need Microsoft.EntityFrameworkCore.SqlServer.
Finally, xunit is the package we will be using for the unit tests and dotnet-text-xunit adds tooling support for Visual Studio. Note that the UnitTests project is a .NET Core App 1.0 (netcoreapp1.0), that Microsoft.EntityFrameworkCore.Design is configured as a build dependency, and Microsoft.EntityFrameworkCore.Tools is set as a tool.
Open Using EF Core Solution from the included source code examples.
Execute the database setup script from the code samples included for this recipe. This can be found in the DataAccess project within the Database folder.
Let's get connected to the database using the following steps:
Add a new C# class named
Blogwith the following code to theBusinessLogicproject:namespace BusinessLogic { public class Blog { public int Id { get; set; } public string Title { get; set; } } }Create a new C# class named
BlogContextwith the following code in theDataAccessproject:using Microsoft.EntityFrameworkCore; using BusinessLogic; namespace DataAccess { public class BlogContext : DbContext { private readonly string _connectionString; public BlogContext(string connectionString) { _connectionString = connectionString; } public DbSet<Blog> Blogs { get; set; } protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder) { optionsBuilder.UseSqlServer(_connectionString); base.OnConfiguring(optionsBuilder); } } }Add the following connection string to the
appsettings.jsonfile:{ "Data": { "Blog": { "ConnectionString":"Server=(local)\\SQLEXPRESS; Database=Blog; Integrated Security=SSPI;MultipleActiveResultSets=true" } } }In the
Controllers\BlogController.csfile, modify theIndexmethod with the following code:using BusinessLogic; using DataAccess; using System.Linq; using Microsoft.AspNetCore.Mvc; using Microsoft.Extensions.Configuration; namespace UI.Controllers { public class BlogController : Controller { private readonly BlogContext _blogContext; public BlogController(IConfiguration config) { _blogContext = new BlogContext(config["Data:Blog:ConnectionString"]); } public IActionResult Index() { var blog = _blogContext.Blogs.First(); return View(blog); } } }Finally, in
Startup.cs, we need to register theIConfigurationservice so that it can be injected into theHomeControllerconstructor. Please add the following lines to theConfigureServicesmethod:public void ConfigureServices(IServiceCollection services) { services.AddMvc(); services.AddSingleton<IConfiguration>(_ => Configuration); }
The blog entity is created but not mapped explicitly to a database structure. This takes advantage of convention over configuration, found in the code-first approach, wherein the properties are examined and then the table mappings are determined. This is obviously a time saver, but it is fairly limited if you have a non-standard database schema. The other big advantage of this approach is that the entity is persistence-ignorant. In other words, it has no knowledge of how it is to be stored in the database.
The BlogContext class has a few key elements to understand. The first is to understand the inheritance from DbContext. DbContext is the code-first context class, which encapsulates all connection pooling, entity change tracking, and database interactions. We added a constructor to take in the connection string, so that it knows where to connect to.
We used the standard built-in functionality for the connection string, storing it in a text (JSON) file, but this could easily be any application setting store; one such location would be the .NET Core secrets file. We pass the connection string on the construction of the BlogContext. It enables us to pass that connection string from anywhere so that we are not coupled. Because Entity Framework is agnostic when it comes to data sources—can use virtually any database server–we need to tell it to use the SQL Server provider, and to connect to it using the supplied connection string. That's what the UseSqlServer method does.
Approaching the use of code-first development, we have several overarching themes and industry standards that we need to be aware of. Knowing about them will help us leverage the power of this tool without falling into the pit of using it without understanding.
This is a design paradigm that says that default rules dictate how an application will behave, but allows the developer to override any of the default rules with specific behavior, in case it is needed. This allows us, as programmers, to avoid using a lot of configuration files or code to specify how we intended something to be used or configured. In our case, Entity Framework allows the most common behaviors to use default conventions that remove the need for a majority of the configurations. When the behavior we wish to create is not supported by the convention, we can easily override the convention and add the required behavior to it without the need to get rid of it everywhere else. This leaves us with a flexible and extendable system to configure the database interaction.
In our example, we use Microsoft ASP.NET MVC. We would use MVC 5 for Entity Framework 6 and .NET 4.x, and MVC Core 1 for Entity Framework Core 1 and .NET Core, and, in both cases, the Razor view engine for rendering the UI. We have provided some simple views that will allow us to focus on the solutions and the code without needing to deal with UI design and markup.
One of the SOLID principles of development, the Single Responsibility Principle (SRP), states that every class should have only one reason to change. In this chapter, there are several examples of that in use, for example, the separation of model, view and controller, as prescribed by MVC.
Entities in code-first have the structure of data as their singular responsibility in memory. This means that we will only need to modify the entities if the structure needs to be changed. By contrast, the code automatically generated by the database-first tools of Entity Framework inherits your entities from base classes within the Entity Framework Application Programming Interface (API). The process of Microsoft making occasional updates to the base classes of Entity Framework is the one that introduces a second reason to change, thus violating our principle.
Entity Framework relies on providers for achieving different parts of its functionality. These are called providers, and the most important, for sure, is the one that supplies the connection to the underlying data store. Different providers exist for different data sources, from traditional relational databases such as SQL Server, to non-relational ones, such as Redis and Azure Table Storage. There's even one for abstracting a database purely in memory!