Entity Framework Core 5.0: The Next Generation for Data Access 

I've meet Jeremy at a talk before and he is a master at explaining stuff, and a really chill dude

2.5 min at 2x speed. That's quite a ride!

@@michaelsimmons2497 1.75 minutes a 4X

@@willinton06 seems like your player is no longer working properly 😆

Also, TPH breaks db normalization. TPT is the "correct" method and should be encouraged. With proper relationships and indexes in place, joins should not be a major performance concern.

Coming from WebObjects, yes after 30 years Microsoft's ORM is still only very basic. There is no GUI mapping tool. No entity to entity (1 to 1/ 1 to many/ many to many) relation mapping. No caching options. Not thread safe. The list go on... Many many years ago in a Spring class, the instructor said he has a buddy working for Microsoft in the middle of working on a ORM solution. Bill Gate personally came down to stop him. A ORM would hurt their SQL Server sale.

@@adamc1694 sorry, but i don't see how an orm coud impact sq server sales, could you please elaborate?

@@hck1bloodday You haven't seen WebObjects's ORM implementation created some 30 years ago. WebObjects's ORM framework has a central object store. So most of the operations are shifted away from the databases to the application servers. If the data (a table record for example) is already in the object store then no SQL will need to fry up again. To compare: 1. Microsoft's solution: 1000 concurrent users browse the data driven web page, 1000 copies of the same record will be fetched and stored in the application. 2. Apple's solution: 1000 concurrent users, only one actual record is fetched and kept in the application. Instead the application only keeps track of changes somewhat like the astracking in EF Core. When one of the 1000 users makes a change, the framework will send a notification to the other 999 sessions and their records will be updated automatically. Again no SQL except one will be involved.

@@adamc1694 @Adam C caching isnt even the default behavior, and it is not a good default anyway. How do you manage freshness? How do you deal with horizontal scaling? How about devs who enable caching for a table with 10k records? It's a nice option to have but when you're releasing to a huge community you have to be selective with features you release. Caching is not simple and not a core functionality of an ORM. Keeping it out of the ORM is the correct decision IMHO.

I've come to the same conclusion. I spent too many hours banging my head against EF trying to figure out how to map my clean domain model to a messy legacy database structure. In the end, I gave up and used Dapper and mapped manually. Yes, I lose change tracking and lazy loading, but I actually deliver business value.

Same!

I am a junior dev still in college but I can say that I have had enough issues with EF Core that I now just use it for writes and stick with Dapper for queries. It does help with migrations and db generation but I'm not sure if Dapper has options there now. I don't trust these contrived examples. With EF you say darn how do I do this thing I should surely be able to do and you check github and it's a request 8 years in the making...looking at you filtered includes and many-many relationships...at least the latter had a proper workaround.

I'm using efcore in a generic repository pattern, but I'm using it only for cruds. For complex queries I prefer dapper too.

Like every ORM throughout history, they're chasing rainbows. With every generation of every ORM, it's all "this time it's going to be great" - up until reality kicks back in, which is usually half way through a big project with a deadline. Just don't. Don't buy into the ORM delusion. It's fundamentally not a good idea, and no amount of clever features is going to fix this. Give me query builders or give me death.

do u think EFCore 5-6 is not really useable for medium-tolarge business projects??

I’m pretty sure you can do that

Wouldn't that be about linq instead of entity?

That's acutally interesting and I'd like to know if EFCore has improved in that area. It could be an extension method / wrapper around IQueryable. I think that if the expression engine can't translate it to SQL you will end up with an error or, even worse, the deferred execution stops and you'll pull way more data to the client than you expected, applying all the remaining operations on the client side instead.

What exactly do you mean? What are "custom fields"? Doesn't make any sense from c# or sql perspective.

@@ICanSeeSharp To be able to create a 'Profile' for a filed? For example firstname, lastname, companyname....instead of doing a repeating annotation (max length, required...) on each xxx-name, why not to be able to create a custom profile and apply to all these xxxname.

@@adamc1694 If I understand correctly what you want, you can create a "Name" class and use it as a owned entity for the main table, and you can configure it using the same configuration everywhere check this out github.com/dotnet/efcore/issues/15681#issuecomment-537789913 I've been using it for a year now :) and you can automate the configuration (even without owned entities) for all tables using reflection and the modelbuilder

I know! New to EF but not data modeling and... why does this feature exist??

It doesn't he is just showing you how to add a field to the m2m table. Btw you can add property .HasDefaultValueSql("getutcdate()") which is outside this topic

Aren't there community providers already?

We're considering it. It was the most requested new provider so there's certainly demand.

@@JeremyLikness Awesome! Not to put you on spot, it's only for me to prioritize my development and my roadmap, *IF* the decision is approved, what would be a rough estimate that it will be GA? Thanks for the reply

@@BenHayat Too early to make any commitments or even guesses as to a timeframe or whether there will be work there.

@@JeremyLikness Thanks!

EF Core does support table splitting, where multiple classes are mapped to a single table: docs.microsoft.com/en-us/ef/core/modeling/table-splitting

Shocking indeed. We use a different mapper and have been able to use all these features with C# since more than 15 years!!! I used EF in a project about 5 years ago and experienced so many missing features that we haven't used EF since. EF is catching up and now has features that I miss in our tool. Still: In many scenarios EF is clearly better than native database programming without a mapper.

@@PeterBuchmann I does not matter, in 10 years AI will write the code, and we both will be jobless/ forced to change job :D

Yes. Less is more. Unfortunately, it takes a long time for most developers to arrive at this kind of clarity. Distractions like yet another ORM making bold, unrealistic claims adds years of wasted learning and unlearning to this path. I wish I knew how to guide new developers around all these obstacles, but I guess maybe it's just a painful rite of passage that every poor misguided developer has to get dragged through.

Well no it really isn't complex EF is great when you want a small database setup quickly write your domain model and bum you have a database backing it up. You really shouldn't use it to map a gigantic database with hundreds of tables or create such databases with it. Like you can have an App running on docker or web app in five minutes with an sql database or cosmosdb and cicd,that all you should need for a small service.

Re nullability enforcement with TPH, that's pretty trivial to achieve with check constraints (github.com/dotnet/efcore/issues/20931 tracks EF doing this for you). Other than that, the intention wasn't to tell anyone they're doing it wrong :) But over the years we've definitely seen TPT designs with deep hierarchies, causing very real perf issues, because of normalization ideals - just be aware of what you choose is all I'm saying.

One of the main points of an ORM is so developers don't have to be SQL experts as well. If you are already a DBA then you don't need this.