We will create our Database with the help of the Entity Framework Core (also known as EF Core), the well-known open source Object Relational Mapper (ORM) for ADO.NET developed by Microsoft. The reasons for such a choice are many:
- Seamless integration with the Visual Studio IDE
- A conceptual model based upon entity classes (Entity Data Model or EDM) that will enable us to work with data using domain-specific objects without the need to write data-access code, which is precisely what we’re looking for
- Easy to deploy, use, and maintain in development and production phases
- Compatible with all the major open source and commercial SQL-based engines, including MSSql, MySql, PostgreSql, Oracle, and more, thanks to the official and/or third-party EF-compatible Connectors available via NuGet
It’s worth mentioning that Entity Framework Core was previously known as Entity Framework 7 until its latest RC release. The name change follows the ASP.NET 5 / ASP.NET Core perspective switch we already talked about, as it also emphasizes the EF Core major rewrite/redesign if we compare it to the previous installments.
You might be wondering why we’re choosing to adopt a SQL-based approach instead of going for a NoSQL alternative; there are many good NoSQL products such as MongoDB, RavenDB, and CouchDB that happen to have a C# connector library. What about using one of them instead?
The answer is rather simple; they are not yet supported by Entity Framework Core 2.0, which--at the time of writing--happens to be the latest stable release. If we look at the EF Core team backlog, we can see that non-relational Database providers such as Azure Table Storage, Redis, and others are indeed mentioned for upcoming support, yet it’s unlikely that we’ll be able to see any of them implemented within the EF Core’s next releases as well.
If you want to know more about the upcoming release, and/or if you feel bold enough to use it anyway--maybe with a NoSQL DB as well--we suggest you read more about the EF Core project status by visiting the following links:
Project Roadmap:
https://github.com/aspnet/EntityFramework/wiki/Roadmap
Source Code on GitHub:
https://github.com/aspnet/EntityFramework
Official documentation:
In order to install Entity Framework Core, we need to add the relevant packages to the dependencies section of our project file. We can easily do that using the visual GUI in the following way:
- Right-click on the TestMakerFreeWebApp project.
- Select Manage NuGet Packages.
- Ensure that the Package source drop-down list is set to All.
- Go to the Browse tab and search for the packages containing the Microsoft.EntityFrameworkCore keyword:
Install the following packages (latest at the time of writing):
- Microsoft.EntityFrameworkCore version 2.0.1
- Microsoft.EntityFrameworkCore.SqlServer version 2.0.1
- Microsoft.EntityFrameworkCore.SqlServer.Design version 2.0.0-preview1-final
- Microsoft.EntityFrameworkCore.Tools version 2.0.1
- Microsoft.EntityFrameworkCore.Tools.DotNet version 2.0.0
If we prefer to do that using the NuGet package manager command line, we can input the following:
PM> Install-Package Microsoft.EntityFrameworkCore -Version 2.0.1
PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer -Version 2.0.1
PM> Install-Package Microsoft.EntityFrameworkCore.SqlServer.Design -Version 2.0.0-preview1-final
PM> Install-Package Microsoft.EntityFrameworkCore.Tools -Version 2.0.1
PM> Install-Package Microsoft.EntityFrameworkCore.Tools.DotNet -Version 2.0.0
Among the installed namespaces, we can easily note the presence of Microsoft.EntityFrameworkCore.SqlServer, which is the Microsoft SQL Database Provider for Entity Framework Core. This highly versatile connector provides an interface with the whole Microsoft SQL Server Database family, including SQL Server 2008 to 2016, as well as the Express and Compact editions for personal and development usage.
We’re free to choose between using one of them and picking another DBMS engine such as MySQL, PostgreSQL, or any other EF-compatible product. Should we take this decision now? It entirely depends on the data modeling approach we want to adopt; for the time being, and for the sake of simplicity, we choose to stick to the MS family.