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.
@@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.
As usual, another great release of EF-Core. Thank you and your team for the great work. All these features are grealty welcomed by myself, especially of course, the many-to-many. Also, fantastic succinct presentation, obviously well-planned.
Great and clear explanations at a nice beat. BUT I have a lot of difficulty to be agree with you about using one table per hierarchy. It goes directly against "Normal form" (Boyce-Codd) and every advantages it has. Yes performance could be better in some case using one table oinly but it could also be less in some other cases. Plus, you have a lots of disadvantages of having unusefull fields in some cases and some other in other cases. You can loose a lot doing so in many ways (integrity, space, some performance on full table scan, etc). It could really become a huge mess.
@19:51 - Line 30: I always liked the T-SQL BETWEEN-Statement. Is an Extension possible for "MemberSince" to be used inside the lambda-expression? like: m.MemberSince.Between(a,z)
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.
@@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 have a problem configuring SQL Server in the function AdddbContext, i can't use the options.UseSQLServer function to insert my connection string, there is some reference or extension im missing?
My error with me is : PM> dotnet ef migrations add migracao1 Build started... Build succeeded. Unable to create an object of type 'ApplicationDBContext'. For the different patterns supported at design time, What happen ? .Net core 5
I've used every version of EF over the years and I've finally come to the conclusion that I simply don't need an ORM. I see no benefit. I now prefer to use something like dapper to query the database and create simple objects. It's lightweight and very fast and I can write sql as my query. I find ORMs like EF to be so restrictive.
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.
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.
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.
I have not been able to target net standard 2.x in Winforms, the only way I have been able to use Net Standard 2.x in WinForms is from a class library.
Came across a wierd phenomenon in EF Core 5.0 . . . class A; class B : A; class C; c = new C; c.b = new B; _context.Add(c); _context.SaveChanges(); // after saving changes let's check what we have in c.b // if B is configured as TPH then c.b is equal to b // if B is configured as TPT then c.b is null, but b is OK
Is TPT coming to EF Core 3.1? I can't imagine it being hard to backport it, so .NET Framework 4 users can use it in their projects as well. That would give them a great head start to at least port the data access and data logic layers of their legacy applications to .NET Standard 2.0 opening their applications for future migration to .NET5.
@@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
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
Many to Many relationship as it is shown on the new WAY of doing it, is actually limiting the access to the data only to EF, and is using a lot of CPU and memory in real time when the query is performed. This can lead to problems with the performance especially when the dimensions of the data becomes hundreds of giga per table.
Just upgraded ef core 2.2 to ef core 5 and I don't recommend anyone to do it, so many bugs and things that don't work as expected, you can see the issues section in github here: github.com/dotnet/efcore/issues Every few minutes someone is submitting a new bug including my self. Even though ef core 5 solves a few issues that were problematic with efcore 2.2 I still prefer the old version due to many bugs efcore 5 has.
I would have liked to see how could we integrate and debug some of these new features within a containerization approach type of programming. Remember, very few people can actually write good code. Just writing code it is not quite enough today, in 80’s and 90’s is yes.
I hate these trivial examples. An ORM such as EF gives very little benefit if it's a 1:1 mapping between classes and DB tables. I would love to see a complex mapping scenario where data for one class is coming from multiple database objects, or vice versa where one table gets mapped into multiple classes.
Try not to reinvent the wheel and simplify thing using current theory, not changing the existing one.That 's why javascript is gaining users and you are loosing ones.
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.
Wow, you can really tell how much they hated adding TPT to core (#1 request for 4+ years). He just happens to skip the mortal sins of TPH, such as the db no longer able to enforce nullable operations. With TPH you can't have any of the properties on ExternalUser be non-nullable; By design they have to be nullable in the database. I appreciate that Shay like's First Normal better than Third Normal, but for heavens sake don't tell US we are doing it wrong. I hope the SQL Server team was watching this, I'm sure they all had a grand laugh when you said "joining tables is hard"... Lol.
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.
It seems C#, .NET continue to become more and more, unnecessarily complicated. One of the biggest mistake EF creators/coders have made is that they assume coders want to create a database using C#. EF now appears to be more bloated than ever, with too many classes. Shortest code is not always the shortest, and is not always the easiest to maintain. By increasing the learning curve the authors of this bloated software are simply shortening the lifespan of the products. Coders get easily excited with everything new, it does NOT mean the "new" stuff is actually easy to use or offers any benefit. The simplest solution almost always is the best solution.
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.
OH PLS what next generation??? It's sooo next generation you cant even write raw sql and select 1 column! SO next generation that if your primary key is LONG you cant use int without cast to use Method Find.
Why not just leave the database alone as it is. If you want a table just create a table in the DB and then query it in the code, simple and easy to understand! The EF problem nowadays is trying to do everything to a database. Before you could create a table properly in the EF code you will have to study like 1 hour manual to accomplish 5 min job. Of course it will be powerful when you have like 500 pages manual, but before that you will have to have a good memory and patient to remember all of these. A good tool for me is to decrease but not to increase the complexity of my job...
Its insane how he explained ef core in 5 minutes
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 😆
This is one of my favorites from the whole event. Very information dense and very well explained!
Very excited to try out these new EF Core features. Keep on with the updates!!
How nice to see things getting easier to do. Thanks!
Nice demo!
Just tiny error I think: at 19:15 you are querying for the oldtimer members, but the query used actually looks for the newbies instead.
It took 13 years for EF to properly support many-to-many relationships.
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.
You explain things very well, Jeremy :)
Shay Rojansky => this is the style I like someone to explain. thanks
As usual, another great release of EF-Core. Thank you and your team for the great work.
All these features are grealty welcomed by myself, especially of course, the many-to-many.
Also, fantastic succinct presentation, obviously well-planned.
Excellent and clear talk, thank you. At 20:00, line 30, should not oldTimers be those before the date, not after?
The new way of joining tables is just amazing. Thanks a lot for the improvement.
Im happy to see the features of EF are now into EF Core 5. Its like a christmas day
Can you serialize these many:many relationships? How do you handle self referencing loops?
Lovely features as always, thank you microsoft!
Hobby projects where perf doesn't matter, ToTable inheritence is really sweet.
do u think EFCore 5-6 is not really useable for medium-tolarge business projects??
very excited to use EF Core 5 :)
Thanks guys, some pretty cool stuff there! Am looking forward to working with these new features.
very excited to use EF Core 5
Excited to that TpT feature.
We can't execute the raw query why this feature is missing ? We have to use dapper ORM ?
Great and clear explanations at a nice beat. BUT I have a lot of difficulty to be agree with you about using one table per hierarchy. It goes directly against "Normal form" (Boyce-Codd) and every advantages it has. Yes performance could be better in some case using one table oinly but it could also be less in some other cases. Plus, you have a lots of disadvantages of having unusefull fields in some cases and some other in other cases. You can loose a lot doing so in many ways (integrity, space, some performance on full table scan, etc). It could really become a huge mess.
Where can we find this demo?
@19:51 - Line 30: I always liked the T-SQL BETWEEN-Statement. Is an Extension possible for "MemberSince" to be used inside the lambda-expression? like: m.MemberSince.Between(a,z)
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.
Very Well Explained , I was waiting for that many to many relationship change , excited to use EF Core 5.
Guys thank you for the demo, this is really informative. Amazing work.
What about custom fields for all tables this simple feature has been lacking for ages.
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
how you do left join and then group by ?
Typo at 2:12, POCO (Plain Old C#/CLR Object)
However I don't know why it is old 😅
These guys are wicked smart. Good stuff.
I have a problem configuring SQL Server in the function AdddbContext, i can't use the options.UseSQLServer function to insert my connection string, there is some reference or extension im missing?
My error with me is : PM> dotnet ef migrations add migracao1
Build started...
Build succeeded.
Unable to create an object of type 'ApplicationDBContext'. For the different patterns supported at design time,
What happen ? .Net core 5
I would just like to point out how easy ef core is once you learn it , it makes a lot of sense
Is there any link to an example code for the second part by Shay Rojansky
?
Thanks.
Great and simple explanation
amazing update and great explanation
WOW! I am loving this... Thanks Guys!
I wished EF Core 5 could update a record without querying it first. I wonder why this feature is missed.
I’m pretty sure you can do that
Oh, so TPC is not introduced yet? =(
I've used every version of EF over the years and I've finally come to the conclusion that I simply don't need an ORM. I see no benefit.
I now prefer to use something like dapper to query the database and create simple objects. It's lightweight and very fast and I can write sql as my query. I find ORMs like EF to be so restrictive.
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.
Great demo. really cool and needed features
I have not been able to target net standard 2.x in Winforms, the only way I have been able to use Net Standard 2.x in WinForms is from a class library.
How on earth the second time you run it didn't stop on the breakpoint?
thank you what about azure functions with dotnet 5?
Came across a wierd phenomenon in EF Core 5.0 . . .
class A;
class B : A;
class C;
c = new C;
c.b = new B;
_context.Add(c);
_context.SaveChanges();
// after saving changes let's check what we have in c.b
// if B is configured as TPH then c.b is equal to b
// if B is configured as TPT then c.b is null, but b is OK
Is TPT coming to EF Core 3.1? I can't imagine it being hard to backport it, so .NET Framework 4 users can use it in their projects as well. That would give them a great head start to at least port the data access and data logic layers of their legacy applications to .NET Standard 2.0 opening their applications for future migration to .NET5.
Very bad support with Oracle database . scaffolding generating wrong data type column. number(4) converting in bit instead of int
thank you for demoing something.
Great features, thank you!
When can i find the source code for reference ?
Jeremy, since EF5 supports NoSQL CosmoDB, is there plan for EF to support MongoDB?
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!
It would be great if EF Core supported arrays of primitive types for Cosmos DB.
Its insane to use class table mapping things.
I know! New to EF but not data modeling and... why does this feature exist??
How does the MemberSince property automatically "know" it should store creation date by just declaring it? :)
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
When will EF Core be compatible with MongoDB and other NoSQL DBs???
Aren't there community providers already?
Really nice👍🏼
Ef doing many to many, I can not believe it
oh jesus I spent 8 hours today debugging my queries, where were you be earlier?
Many to Many relationship as it is shown on the new WAY of doing it, is actually limiting the access to the data only to EF, and is using a lot of CPU and memory in real time when the query is performed. This can lead to problems with the performance especially when the dimensions of the data becomes hundreds of giga per table.
8:24 This package (www.nuget.org/packages/ObjectStore/) can do this for years already.
Comos Db supports arrays of privative types but Entity Framework Core Cosmos Db does not. It's a huge issue.
Great but. why don't you fixed migration issue for .net standard 2.1
What would be really cool: if you could take a sql query and produce an EF query....
unfortunately there is still no improvement in database first approach as we have to re-create whole entities for just small change
Love EF
Isn't the oldTimers query reversed? Shouldn't the "oldTimer" be those with a membership < new DateTime(2000..... ???
.net 5 is same like .net core 3.1 major changes are c# 9 and internally performance enhanced
Pretty cool
Nice Video
Yikes a discriminator is VARCHAR(MAX). You cannot index a varchar(max). Could cause speed problems later on.
I don't see any new feature, they all already exists :-)
Lacking of support in azure functions makes ef core 5 useless
Great
9:35 LogTo
GraphQL and real time apps - should be native by now
Awesome.
Many to many!!!!!
Add configuration capability to Owned() and selectively ignorable global query filters to Fluent API, or a bunny will die.
Using Sublime over VSCode?
Just upgraded ef core 2.2 to ef core 5 and I don't recommend anyone to do it,
so many bugs and things that don't work as expected, you can see the issues section in github here: github.com/dotnet/efcore/issues
Every few minutes someone is submitting a new bug including my self.
Even though ef core 5 solves a few issues that were problematic with efcore 2.2 I still prefer the old version due to many bugs efcore 5 has.
I would have liked to see how could we integrate and debug some of these new features within a containerization approach type of programming.
Remember, very few people can actually write good code. Just writing code it is not quite enough today, in 80’s and 90’s is yes.
So which is better, EF or NHIBERNATE?
I hate these trivial examples. An ORM such as EF gives very little benefit if it's a 1:1 mapping between classes and DB tables. I would love to see a complex mapping scenario where data for one class is coming from multiple database objects, or vice versa where one table gets mapped into multiple classes.
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
12:00
Microsoft Developer using Firefox on a stream... How? :)
Try not to reinvent the wheel and simplify thing using current theory, not changing the existing one.That 's why javascript is gaining users and you are loosing ones.
hibernate all the way
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
Wow, you can really tell how much they hated adding TPT to core (#1 request for 4+ years). He just happens to skip the mortal sins of TPH, such as the db no longer able to enforce nullable operations. With TPH you can't have any of the properties on ExternalUser be non-nullable; By design they have to be nullable in the database. I appreciate that Shay like's First Normal better than Third Normal, but for heavens sake don't tell US we are doing it wrong.
I hope the SQL Server team was watching this, I'm sure they all had a grand laugh when you said "joining tables is hard"... Lol.
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.
I definitely stick with ADO.NET for transactions and for DAPPER queries
It seems C#, .NET continue to become more and more, unnecessarily complicated. One of the biggest mistake EF creators/coders have made is that they assume coders want to create a database using C#. EF now appears to be more bloated than ever, with too many classes. Shortest code is not always the shortest, and is not always the easiest to maintain. By increasing the learning curve the authors of this bloated software are simply shortening the lifespan of the products. Coders get easily excited with everything new, it does NOT mean the "new" stuff is actually easy to use or offers any benefit. The simplest solution almost always is the best solution.
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.
2021 and explaining Entity framework like they invented the hot water.... hibernate is in java since 2010 and other ORMs are in JS since 2015....
Slow down Shay 🙄 anyway good job guys
This looks like code first. If you are interested in data first don't waste your time with this video.
Still way far behind NHibernate.
WPF? 2020? Come on guys, you can do better than selling WPF in 2020... even 2021
OH PLS what next generation??? It's sooo next generation you cant even write raw sql and select 1 column!
SO next generation that if your primary key is LONG you cant use int without cast to use Method Find.
Why not just leave the database alone as it is. If you want a table just create a table in the DB and then query it in the code, simple and easy to understand! The EF problem nowadays is trying to do everything to a database. Before you could create a table properly in the EF code you will have to study like 1 hour manual to accomplish 5 min job. Of course it will be powerful when you have like 500 pages manual, but before that you will have to have a good memory and patient to remember all of these. A good tool for me is to decrease but not to increase the complexity of my job...
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.
Better late than never...
Shay started a race of coding. Slowdown man I can't sync with your code.
That awkward moment when you're using Firefox but not your own Microsoft Edge.