LLBLGen vs Entity Framework Core

Posts   
 
    
mdbruning
User
Posts: 18
Joined: 10-Mar-2008
# Posted on: 10-Jul-2020 10:56:04   

Hello all,

I have been working with LLBLGen for something like the past 12 years or so and I am very happy about it. However, I am part of a new development team now where most of the devs seem to lean towards Entity Framework Core.

Is there anyone here that has a good comparison of LLBLGen vs EF Core, which can help me to convince the others to choose LLBL?

I know I am convinced, but would like to know the experiences of others, who perhaps have used both.

Cheers, Mathieu

Otis avatar
Otis
LLBLGen Pro Team
Posts: 38628
Joined: 17-Aug-2003
# Posted on: 10-Jul-2020 11:12:45   

Our designer supports EF Core too, so if you want to keep using the designer, you don't have to switch away.

For the runtime framework itself:

EF Core has way less features than our framework and in general is slower. Way less features as in: TVF support, stored procedure support, prefetching related data in an efficient way support, TPT inheritance, M:N relationships, multiple catalogs per project, schema/catalog name overwriting, no authorization, no auditing, no allowed-actions support (readonly entities, read/update entities etc.), no separate Unit of work, so you have to collect work with a live dbcontext, no multi-versioning of entity field values and I could go on and on but it gets a tedious list stuck_out_tongue_winking_eye

It supports 'poco' entities, which we don't, but as in general the models exposed to e.g. views or from services are anemic (DTO style) anyway, you need a model on top of your entities in most cases, which makes the whole 'poco' requirement moot. (and you can define a derived model easily with our designer for both frameworks)

EF Core has 1 query system: Linq. This is limiting in a lot of cases. We have 3 typed query systems which you can use whenever you like (you don't have to pick one and stick with it). EF Core does have a limited plain SQL api for fetching but not like we have.

We ship a DQE for all databases we support, for EF Core you have to use the query engine shipped by the provider of your database. With Oracle for instance this is a problem, as Oracle's provider is pretty bad. Not sure if you're using oracle tho.

The support for things you want to have fixed is in EF Core limited: a fix isn't made within a day or 2 like with us, but chances are you have to wait till the next version.

The main thing with EF Core is that although it 'works' for a lot of cases, there are a lot of small things that aren't there or not flexible enough. Our framework gives you a lot of extension capabilities so you can adjust the way it works how you see fit.

One thing I'd like to add as closing: if they pick EF Core and write their entity classes by hand, they're doing a code generator's work, poorly. I don't know how big your domain model is, but say it's 80 entities, that's a lot of typing: not only the classes, but also the mappings. Someone will have to maintain these for the lifetime of the application. That's something they likely haven't thought of, or don't care about, but it's part of the application code that'll become a burden for the maintainers who'll take over.

You can also outsource that to a click of a button. simple_smile

Frans Bouma | Lead developer LLBLGen Pro
mdbruning
User
Posts: 18
Joined: 10-Mar-2008
# Posted on: 10-Jul-2020 16:23:09   

Thanks for the extensive reply Otis! This definitely helps!

Do you know if there are any benchmarks available for recent versions of LLBLGen vs EF Core?

Thanks again and have a great weekend!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 38628
Joined: 17-Aug-2003
# Posted on: 11-Jul-2020 08:27:14   

We have a microbenchmark with most micro/full ORMs for .net, called RawDataAccessbencher.

The latest public results are from April 2020 and contain EF Core 3.1.3 and LLBLGen Pro 5.6 (5.7 didn't receive any optimizations of significance, the results are more or less on par with 5.6)

.net core 3.1: https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/20200410_netcore31.txt

.net fx: (no efcore 3.1.3 as it's .net standard 2.1) https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/20200410_netfx.txt

source, so you can run them yourself: https://github.com/FransBouma/RawDataAccessBencher

Note: micro ORMs, including linq to DB, don't have complex persistence logic so you have to write the entity services/persistence ordering/unit of work/pk syncing etc. etc. yourself and maintain that, so although their fetch code is often slightly faster (it's close together except EF6/NH which are slow), it's just part of the story.

the batch benchmark for inserts shows linq to db being very fast. It uses the bulk copy api for data imports here. This is very fast but also very limited in scope (inserting multiple types of elements isn't possible for instance).

See the benchmarks as an indication how the frameworks relate to each other with these specific fetch / insert queries.

You too have a good weekend, and if your colleagues have questions, let me know simple_smile

Frans Bouma | Lead developer LLBLGen Pro