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

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

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.

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!

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

most of the devs seem to lean towards Entity Framework Core

The problem with EF Core is that you have to worry about what new major versions would bring. I like my ORM to be a solid rock, not a shifting sand.

dodyg wrote:

most of the devs seem to lean towards Entity Framework Core

The problem with EF Core is that you have to worry about what new major versions would bring. I like my ORM to be a solid rock, not a shifting sand.

Yes, it's a feature to be able to keep using an orm for a long period of time as the app you're using it with might run a long period of time.

This is a very good list.

We are starting a ASP.NET project using EF Core 5.0. I would like to use LLBLGen Pro for tasks in which it saves us time, for example to maintain the entity classes whenever changes are made manually to the database schema.

Can you please explain in which ways you can combine use of LLBLGen Pro with EF Core without compromising the ability to use EF Core whenever we choose.

Thank you

Otis wrote:

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

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.

I don't understand your question... it generates entity and modelbuilder classes, like you would by hand. They don't rely on a runtime we ship ourselves, it's code you otherwise would have written yourself. You can generate it and e.g. from there hand-modify it from then on if you want to. The only thing that's not there are SQL types in the mapping files. In general this isn't that much of a big deal as production databases often aren't generated 'at app start' but with predefined scripts.

Thank you.

Otis wrote:

I don't understand your question... it generates entity and modelbuilder classes, like you would by hand. They don't rely on a runtime we ship ourselves, it's code you otherwise would have written yourself. You can generate it and e.g. from there hand-modify it from then on if you want to. The only thing that's not there are SQL types in the mapping files. In general this isn't that much of a big deal as production databases often aren't generated 'at app start' but with predefined scripts.

Otis wrote:

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

Any thoughts on when the benchmarks will be updated for .NET 6? I know at the .NET Conference they talked about a fairly significant performance increase but I'm curious how "significant" it really is.

I'll run new benchmarks when 5.9 goes into beta (which should be within 2 -3 weeks). We haven't done performance work on the runtime tho as it's been optimized to death already and I don't really see any tricks left to try that will give a big boost (as there's little room left anyway) and not cut corners.

EF Core 6 claims to be faster, but I find the whole story pretty odd. They're already close/faster than dapper in my benchmarks with non-changetracking fetches. https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/20210615_net5.txt#L70 and a lot of the optimizations seem to be tailored towards cutting corners in the TechEmpower benchmarks. We'll see

Otis wrote:

I'll run new benchmarks when 5.9 goes into beta (which should be within 2 -3 weeks). We haven't done performance work on the runtime tho as it's been optimized to death already and I don't really see any tricks left to try that will give a big boost (as there's little room left anyway) and not cut corners.

EF Core 6 claims to be faster, but I find the whole story pretty odd. They're already close/faster than dapper in my benchmarks with non-changetracking fetches. https://github.com/FransBouma/RawDataAccessBencher/blob/master/Results/20210615_net5.txt#L70 and a lot of the optimizations seem to be tailored towards cutting corners in the TechEmpower benchmarks. We'll see

Sweet thanks!