Is Entity Framework Core Production Ready?

Is Entity Framework Core ready for production? Should I use EF 6 instead?

Building a .NET Core app and want to know whether EF Core is ready for showtime yet?

I’ve seen this question crop up a few times and I think the honest answer is “it depends”.

Yeah, I know… but it really does depend on what you need it for.

For most “simple” operations EF Core will work fine and is a pretty safe bet given that it’s been developed by a Microsoft team alongside .NET Core.

The same team is responsible for building both EF Core and EF 6 so expect them to be a little stretched over the coming weeks and months as they switch between projects (something you can monitor yourself by looking at the commit frequency for EF Core).

It’s worth noting from the official GitHub wiki that there are a number of “critical O/RM” features missing which will need to be implemented before the team consider EF Core to be the “recommended version of Entity framework”.

These include GroupBy translation. With the current version, if you attempt to perform a group by operation it’s performed in-memory meaning all the necessary data is retrieved first, then processed in-memory rather than a SQL statement being employed to perform the Group by operation.

The impact of this depends on the size of your data. It probably won’t make much difference if you’re dealing with small amounts of data but could represent a significant bottleneck if you’re trying to work with a lot of data as EF will have to pull it all back from the database before performing the group by.

This kind of client side processing is referred to as “Client Evalution” and the good news is you can make sure you always know when it’s happening with a small tweak to configuration.

By default EF Core will log warnings when client evaluation is performed. The following code tweaks the configuration to throw an exception (useful if you don’t want to use any features which result in client evaluation, this will effectively prevent that from happening by throwing an exception instead).

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder
        .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFQuerying;Trusted_Connection=True;")
        .ConfigureWarnings(warnings => warnings.Throw(RelationalEventId.QueryClientEvaluationWarning));
}

See the official docs for more information.

Lazy Loading is another key missing feature. Lazy Loading enables properties to be automatically populated from the database at the moment they’re accessed (rather than in one go, up-front).

There are a few others. Check the official wiki when making your decision.

Here’s the key information if you to decide to try it.

Entity Framework Core

GitHub: https://github.com/aspnet/EntityFramework

What about Entity Framework 6

Don’t forget, if you choose to use ASP.NET Core but target the Full Framework then you can continue to use Entity Framework 6 or indeed any other full ORM (and there’s plenty to choose from, including long-standing options NHibernate and the commercial LLBLGen Pro).

If you’re trying to decide whether to go with EF Core or EF 6, this handy feature comparison might help you decide.

What else works with .NET Core?

If you’re happy to do more of the “leg work” yourself, you could use a Micro-ORM instead. These are “lighter” than ORMs; they don’t generally track state or generate SQL queries for you, rather they provide a simpler API for you to execute your own “handcrafted” SQL queries.

Micro-ORMs are generally fast so represent a good option if data access speed is paramount for your app.

Dapper

GitHub: https://github.com/StackExchange/dapper-dot-net

Install-Package Dapper

Open source, free and fast. Dapper was originally created by Sam Saffron at Stack Overflow who continue to use it in production.

If speed is a primary concern for you then Dapper is considered to be one of the top performers.

Dapper supports any database that has a .NET ADO provider (including SQLite, SQL Server, MySQL, PostgreSQL). Check out the homepage for more details.

Dapper works by mapping results to strongly typed objects. For example this retrieves all books from a “Book” table and maps the results to a list of Book objects.

return db.Query<Book>("Select * from Book").ToList();

ServiceStack OrmLite

GitHub: https://github.com/ServiceStack/ServiceStack.OrmLite

To use with SQL…

Install-Package ServiceStack.OrmLite.SqlServer

Service stack has both Open Source and Commercial licenses. Version 4+ is commercial software with free quotas which allows free usage for small projects and evaluation.

.NET Core is supported from version 4.5.2 upwards.

It has NuGet packages for SQLServer, PostgreSQL, MySQL, SqLite, Oracle, Firebird and VistaDb.

LimeBean

GitHub: https://nick-lucas.github.io/LimeBean/

Install-Package LimeBean

An interesting cross between ORM and Micro-ORM inspired by RedBeanPHP, Limebean uses unusual syntax by employing names such as “Bean” to represent a row in a database and “Dispense” to make an empty Bean for a table.

It then provides an API for you to “fill” that bean with data.

var bean = api.Dispense("book");
bean.Put("title", "Three Comrades")
    .Put("rating", 10);

It also supports SQLite, MySQL, PostgreSQL and SQL Server.

SqlFu

GitHub: https://github.com/sapiens/SqlFu

Install-Package SqlFu

Another open source option with support for .NET Core.

SqlFu identifies performance and versatility among its features.

It maps data from a query result to a POCO. It doesn’t make use of Linq but rather a specialised string builder to form the SQL which will be used to query the database.

Here’s an example of a query including a conditional order by which will only kick in based on the value of a variable (input.ShouldSort).

_db.WithSql(q => q.From<User>()
            .Where(d=>d.Id==id && !d.IsActive)
            .OrderByIf(c=>input.ShouldSort,d=>d.Name)
            .SelectAll())
    .GetRows();

Other Options

If you want even more choice be sure to check out the Awesome .Net Core list for more options.