How come? It's one of the few things I'm really missing since switching most of my development work away from dotnet. EF Core + LINQ give you type-safe and very compact queries. I don't think there's anything similar for Hibernate, for example: there is JPA Specification API with metamodel generation. The idea is very similar, but with much more boilerplate.
This means we will probably never get: 1. Ability to pull non entity types out of the database without a whole lot of boilerplate. See the bizarre obstinacy here: https://github.com/dotnet/efcore/issues/10753
2. Any kind of bulk insert/delete/update ability. It's been a "to do" for years now.
3. Much better query composability.
Basically their response is to just use raw SQL for anything that isn't a unit-of-work feature. They're missing a lot of benefits that a ORM could provide when they say that.
The ef.core team feels like a lot of rejects that were stack ranked out to their own team. I know that is mean to say, but they iterate extremely slowly compared to teams like asp.net .core, visual studio code, c# language group, f# language group.
1. Type safety/refactorability
2. Composability (can I reuse my queries)
3. Expressivity (can I generate the queries I want)
Of these, EF only solves the first, which is far and away the easiest of the three.
Composability in EF is possible via expression tree splicing, however it requires such a degree of discipline and insight that I have never seen anyone do it, or even any discussion around it.
Like almost everything in the .NET ecosystem, EF makes a bunch of promises that are fantastic for hello world, but are disastrous as your project grows.
To be clear you can get a long way by abusing EF's willingness to try and interpret arbitrarily complex expressions - it just provides zero tooling or guidance on how to build those expressions.
Or projections. It's possible to write a reusable projection for EF like so:
class MyTableProjection {
public static Expression<Func<MyTable, MyTableProjection>> Expression =>
t => new MyTableProjection {
Id = t.Id,
Str = t.Str,
Flag = t.Flag
};
public int Id { get; init; }
public string Str { get; init; }
public bool Flag { get; init; }
}
dbContext.MyTable
.Where(...)
.Select(MyProjection.Expression)
.ToListAsync()
[1] https://github.com/scottksmith95/LINQKit [2] http://www.albahari.com/nutshell/predicatebuilder.aspx
Re: Composability
You can generate something like the WHERE clause of a query in a function and return it alone (rather than as a SELECT query) or even combine it with another WHERE.
e.g. In SA the "select" and "where" portions aren't tightly coupled.
Re: Expressivity
Right now you can easily build up ef.core queries by chaining IQueryable.Where, which is nice but you can only do that for selects and something like OR conditions are difficult to implement.
e.g. in SA you can just pass a list of predicates to the or_() function.
e.g. in SA you can build a WHERE clause and then pass the same clause to a select or a bulk operation.