Entity Framework Core can access many different databases through plug-in libraries called database providers.
EF Core providers are built by a variety of sources. Not all providers are maintained as part of the Entity Framework Core Project. When considering a provider, be sure to evaluate quality, licensing, support, etc. to ensure they meet your requirements. Also make sure you review each provider's documentation for detailed version compatibility information.
We have been developing an EF Core provider for the DocumentDB API in Cosmos DB. This will be the first complete document-oriented database provider we have produced, and the learnings from this exercise are going to inform improvements in the design of the subsequent release after 2.1. The current plan is to publish an early preview of the provider in the 2.1 timeframe.
The Oracle .NET team has announced they are planning to release a first-party provider for EF Core 2.0 approximately in the third quarter of 2018. See their statement of direction for .NET Core and Entity Framework Core for more information. Please direct any questions about this provider, including the release timeline, to the Oracle Community Site.
In the meanwhile, the EF team has produced a sample EF Core provider for Oracle databases. The purpose of the project is not to produce an EF Core provider owned by Microsoft, but to help us identify gaps in EF Core's relational and base functionality which we need to address in order to better support Oracle, and to jumpstart the development of other Oracle providers for EF Core by either Oracle or third parties.
We will consider contributions that improve the sample implementation. We would also welcome and encourage a community effort to create an open-source Oracle provider for EF Core, using the sample as a starting point.
Adding a database provider to your application
Most database providers for EF Core are distributed as NuGet packages. This means they can be installed using the
dotnet tool in the command line:
dotnet add package provider_package_name
Or in Visual Studio, using NuGet's Package Manager Console:
Once installed, you will configure the provider in your
DbContext, either in the
OnConfiguring method or in the
AddDbContext method if you are using a dependency injection container. For example, the following line configures the SQL Server provider with the passed connection string:
Database providers can extend EF Core to enable functionality unique to specific databases. Some concepts are common to most databases, and are included in the primary EF Core components. Such concepts include expressing queries in LINQ, transactions, and tracking changes to objects once they are loaded from the database. Some concepts are specific to a particular provider. For example, the SQL Server provider allows you to configure memory-optimized tables (a feature specific to SQL Server). Other concepts are specific to a class of providers. For example, EF Core providers for relational databases build on the common
Microsoft.EntityFrameworkCore.Relational library, which provides APIs for configuring table and column mappings, foreign key constraints, etc.
Providers are usually distributed as NuGet packages.
When a new patch version of EF Core is released, it often includes updates to the
Microsoft.EntityFrameworkCore.Relational package. When you add a relational database provider, this package becomes a transitive dependency of your application. But many providers are released independently from EF Core and may not be updated to depend on the newer patch version of that package. In order to make sure you will get all bug fixes, it is recommended that you add the patch version of
Microsoft.EntityFrameworkCore.Relational as a direct dependency of your application.