Will This New EF Core Feature Be The End Of Dapper?

EF Core is the most popular ORM in .NET. Dapper is often used with EF Core or as a complete substitute because of its raw SQL capabilities and performance. However, EF Core 8 has an exciting new feature: returning unmapped types with basic SQL queries. This is precisely what Dapper offers. Does it make sense to have two dependencies if EF Core can already do it all?

Join my weekly .NET newsletter:

Read my Blog here:

Subscribe for more:

Chapters
0:00 Implementing the GetOrder feature
2:42 Loading an Order with EF Core entities + AsNoTracking
4:35 Better performance EF Core projections
5:59 Installing EF Core 8 preview
6:36 Exposing the DatabaseFacade for raw SQL queries
7:26 Writing Raw SQL queries with EF Core

[dave]

Betteridge's law of headlines. "If a headline asks a question then the answer is almost always no".

[rustamhajiyev]

Finally we have both approaches united under one library 🎉 Waiting for performance benchmarks 😉
Thanks for the content! 😃

[BovIne-gzdz]

Your channel is a blessing to all .Net developers! All power to you reaching 50k subs and beyond 💯

[peterkulik]

I would have solved this case with Dapper by executing 2 selects using the QueryMultiple method.
It would have still been one roundtrip, and there would be no need to add unnecessary complexity to separate the result data...

[thefrugaldeveloper]

Hi Milan, really appreciate the time and effort you put into this stuff. I really wish there would be more content on some of the other tools out there.

[antonmartyniuk]

Wow, that can truly put the need of the Dapper back. Also in this video a nice comparison of 2 libs can be seen and how much easier to query data using high level EfCore features and you get the model you need straight away

[rr.vasconcelos]

I'm studying English a lot to be able to better understand your teachings! Your videos are great

[rustamtaov]

An awesome video, an awesome feature and awesome explanations! I've worked with Dapper for 2 years so it looks so intresting. You also can group data via sql script and miss linq grouping and selecting data

[Bennevisie]

It would be useful to give a brief explanation of the use case you are implementing beforehand. Some of us struggle to follow if we don’t know where you are heading.

[johannesmogashoa]

Man this is the video I tell you. Looking forward to seeing what the benchmarks reveal especially now as my team will be doing a rewrite of one of our projects and we are still debating on whether to go EF Core or Dapper or both. 👀

[jeroen]

This inline sql is a way to create unmaintainable code. Just like stored procedures. If you have lots of this and you want to change your database schema your build works but everything breaks when you run it. the strength of EF is that all code is typed, no magic strings, so changing an enitity class will break all using code during local development. Reducing bugs by a lot.

[alexmarahovsky]

I don't want to disappoint you but EF was always able to compete with Dapper! You just need to compiled (pre-compiled) linq query.

[BrendanAlexander]

Very interesting, thank u! If we are getting nit-picky, there is the overhead of provisioning a dbcontext instance from the db pool every time you need to run a query. Whereas using dapper I would presume it wouldn't rely on as much resources, tho am only speculating here. Will look forward to seeing your benchmarks video!

[aimene_.]

With Dapper or EF, never write SQL Queries in the code. Use stored procedures

[Kingside]

working with childs was, is and will always be a problem.
Dapper comes with the "splitOn" solution where you have to define at which column you want to split. After that you have to add the childs in a separate dictionary.
RepoDB define for itself to not handle childs.
Now this EF 8 Solution is to be honest also cluncy. You have to define a flat-object to group it after that.
It may be not the fastest soulution but EF with just saying .Include(...) gives by far the best readable solution for developers.
Saving childs is by the way possible by define user-defined-types for SQL Server and pass the whole child as parameter. And EF provide also a great solution.

[nicolasundiano]

Hi Milan, is there a way that we can constraint the IApplicationDbContext only for AggregateRoots? Because i like using this feature instead of repositories but i want to constraint that only the ARS can access the iappdbcontext

[TheMdecima]

I just find you searching about ddd, Great content, thanks

[Sergio_Loureiro]

So much thought put into ORM frameworks, and in the end the developer still needs to write SQL queries by hand...

[Noor-hdnf]

Great video Milan. I'm planning an app and I was thinking about using Dapper for reads and EF Core for writes. If this new feature in EF 8 has the same performance as Dapper I will consider it in the future.

[LCTesla]

This is more like EF Core admitting defeat to Dapper by becoming like it.