ORMs for .NET Core

Write for InfoQ

With EF Core struggling to accommodate basic database features such as views and stored procedures, developers are looking elsewhere for their data access needs. Here are some of the more popular options.

LLBLGen Pro Runtime Framework

The LLBLGen Pro Runtime Framework is an optional ORM that works in conjunction with the LLBLGen entity modeling tool. We say it’s optional because LLBLGen can also work with other ORMs such as Entity Framework.

Like Entity Framework, the LLBLGen Pro Runtime Framework is full OOP style ORM. But it differs in several ways, the first being an emphasis on performance. Though EF Core is significantly faster than classic Entity Framework, both are still considerably slower than other ORMs. Frans Bouma, author of LLBLGen Pro, hosts a performance shootout comparing materialization speed of various .NET data access / ORM implementations.

The LLBLGen Pro Runtime Framework also differs from EF/EF Core in that it is not context-bound. Each entity tracks its own changes, allowing you to manipulate an object graph in memory without holding a context open. (Which will make your DBA happy because not holding an open context also means you aren’t holding an open connection, which would otherwise interfere with database connection pooling.)

Like most ORMs for .NET Core, there are some limitations with the Core version of LLBLGen Pro Runtime Framework. However, this is mostly limited to missing features in .NET Core itself such as TransactionScope not being supported by SqlClient or fewer objects being binary serializable.

Dapper

On the other end of the scale is the well-known micro-ORM, Dapper. Often regarded as the fastest ORM, Dapper is consistently at or near the top of .NET ORM benchmarks.

As Dapper is mostly limited to calling raw SQL and materializing the results, it works essentially the same on .NET and .NET Core. Unlike full ORMs, Dapper does not provide any SQL generation capabilities. This tends to make it more verbose than the other ORMs, though many developers don’t trust the SQL that ORMs generate.

LINQ to DB

LINQ to DB describes itself as “one step above micro-ORMs like Dapper, Massive, or PetaPoco”. It lacks many of the features that cause performance issues in Entity Framework to use such as change tracking.

Joins in LINQ to DB are somewhat unusual. In EF, anything you think of as a “join” is really treated as a child object or collection. The SQL it generates will of course use joins, but they are unwound when the result set is materialized as objects.

In LINQ to DB you get actual joins. More specifically, “left joins” and “inner joins”. The syntax is a little weird if you are used to EF’s interpretation of LINQ, but it better matches how the database actually works.

DevExpress XPO

eXpressPersistent Objects (XPO) is another (削除) commercial (削除ここまで)offering. Reddit user -GrapH- has this to say about it:

I've been using DevExpress XPO for 11 years now, and this October it supported .NET Standard 2.0. Even though this is a commercial product, its first .NET beta with .NET Core support (v17.2.2) is going to be free for everyone. Further updates are paid, but they include the visual designer and technical support. While this ORM is different from EF and is older (unless I am mistaken, its first version was released for .NET 1.1), it basically has everything we needed for apps of very different scale. Check https://github.com/DevExpress/XpoNetCoreDemos for demos and tutorials.

UPDATE: DevExpress XPO is now free. For more information see the XPO Team Blog.

What’s your favorite?

There are many more ORMs available for .NET Core. If there’s one that you’ve been using for a few months, let us know what you think about it.

Related Topics:

• Development
• .NET
• ORM
• .NET Core
• Data Access

We protect your privacy.