BT

Your opinion matters! Please fill in the InfoQ Survey!

ORMs for .NET Core

| by Jonathan Allen Follow 259 Followers on Dec 04, 2017. Estimated reading time: 3 minutes |

A note to our readers: As per your request we have developed a set of features that allow you to reduce the noise, while not losing sight of anything that is important. Get email and web notifications by choosing the topics you are interested in.

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.

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.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Did you know... by Paulo Quicoli

NHibernate 5 supports .NET Core

Re: Did you know... by Jonathan Allen

Honestly, I didn't know it was still in development. The last time I heard of anyone using it for new work was in 2013 when they were still struggling to release a .NET 4.0 version and async/await were distant dream.

Have they made any progress in terms of performance? Their reputation as "the only ORM slower than EF" wasn't doing them any favors.

Re: Did you know... by Paulo Quicoli

Hi!
What are your sources? I've being using NHibernate since version 2 and it faster then EF :)

NH supports async now :) it still in development, have a large base of users around the world :)

See you

EntityLite by Jesús López

EntityLite supports .NET 3.5, .NET 4.5 and .NET Standard 2.0. Therefore it runs on .NET Core 2.0. I've been using it since 2009, when I developed it, I published it on 2013. It supports async/await on .NET 4.5 and .NET Standard 2.0 releases.

Re: Did you know... by Jonathan Allen

Here's a benchmark mostly looking at materialization speed.

github.com/FransBouma/RawDataAccessBencher/blob...

NHibernate isn't always the slowest, but it certainly doesn't compare well to the others.

.NET Core should be for big thing by Hung Nguyen

For .NET Core I would like too see more articles about building distributed system such as Microservices with Pivotal Steeltoes or the Polly framework. It’s 2018 and we are still talking about ORM???

Re: Did you know... by Frans Bouma

NH5 doesn't support .NET Core, it's not mentioned anywhere in the release notes and the open issue about porting to core isn't worked on.

Re: .NET Core should be for big thing by Dmytro Lapshyn

Pardon my ignorance, but how exactly would microservices rule out the need for an ORM? Building a microservice does not necessarily imply usage of a NoSQL DB

MicroORM by Karl Godtliebsen

I Am a great fan of ServiceStack OrmLite, simple, fast, convention based, supports .Net Core.

Re: .NET Core should be for big thing by Hung Nguyen

I didn't mean that.

What I meant is, the .NET ecosystem before .NET Core was mostly about ASP.NET , ADO.NET, Entity framework, SQL Server etc. basically all the things needed to build website, web API and that's all. Let's have a search over .NET jobs you can see that, 99% of the .NET job is to build website or simple web API. But have a look Java's ecosystem they have Camel, Karaf, Kafka, Hadoop, Spark, ElasticSearch, Spring Boot, Spring Cloud etc. all the things to build big enterprise / distributed system, not only website.

Now we have .NET CORE, so I hope that there'll be big change to the .NET ecosystem. .NET Core must to be built big, enterprise system, distributed system.

Re: .NET Core should be for big thing by Jonathan Allen

A lot of that stuff simply isn't necessary for .NET.

For example, the equivalent to Sprint Boot is simply the boring old project templates that have been part of Visual Studio since the beginning.

.NET Core drivers for Hadoop or ElasticSearch have been available for awhile and the same way as they would for Java or .NET Framework.

And while I admit that I don't know all of those products, a quick survey of them gives me the impression that each of them is already available for .NET in some form or an unnecessary distraction.

***

To understand my background, I spent 5 years working a on system that would now be described as "micro-services", though we didn't use that term at the time. We just used normal .NET 4.0, WCF, message queues, and Windows Services.

We did have to roll our own solutions for distributed monitoring and configuration, but the total cost of that was probably less than 200 lines of code.

EF Core supports views and stored procedures by Julie Lerman

Do some research before making blanket , dismissive statements like that.

Re: EF Core supports views and stored procedures by Julie Lerman

(i.e. you can map an entity to a view)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

13 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT