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