BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News ORMs for .NET Core

ORMs for .NET Core

Leia em Português

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
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.

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

Community comments

  • Did you know...

    by Paulo Quicoli,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    NHibernate 5 supports .NET Core

  • Re: Did you know...

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • Re: EF Core supports views and stored procedures

    by Julie Lerman,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

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

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

BT