Hey friends, thanks so much for your feedback! 🙏 I wanted to address a few things 👇 Entity Framework: Some of you mentioned using ExecuteUpdateAsync and ExecuteDeleteAsync for updates and deletes. You’re right, and I should have included those to save a database trip. Sorry about that! Dapper: There have been some updates to Dapper that I missed. Thanks for pointing these out! I’ll use the latest methods in my next video. Benchmark: I know the benchmarking part wasn’t perfect. I’ll fix this in a follow-up video to make sure it’s accurate. Thanks again for your support and helpful comments! I’m working on an updated video, so stay tuned! ❤
I'm an old SQL guy. As long as Dapper performs competitively then it will always be my choice. The big difference for me is stored procedures. I can write these in the comfort of SSMS and execute them easily in Dapper with no typos. Thank you Patrick!!!!
When updating and deleting in EF, you should have used the ExecuteUpdateAsync and ExecuteDeleteAsync methods. This way, you don't have to first retrieve the record, saving you a trip to the database. Also, you could have just left out the benchmark part of this video since the results were not valid anyway to avoid confusion.
Thank you for your valuable feedback! You’re absolutely right about the EF methods and the benchmark. I apologize for the mistake and will correct this in a follow-up video. Appreciate your insights!
I would pick SQL over EF any day of the week. Why do I need EF? I know how to create a database, I know how to create tables, I know how to query data in those tables. It is a shame that this has become the default go to for data access in online tutorials etc. I have not been using .NET for a long time and coming from a more direct to SQL experience in the past I am discouraged whenever I check out a video and they start going on about EF, the normal result is I stop watching and find my information from another source. Which I have done many time on your videos. Rather than write SQL directly in the code, swap it out to a stored procedure and then you can debug and modify your SQL query without recompiling your code. As far as I know Dapper has no issue with stored procedures so win in my book. If I know SQL I can easily use Dapper so why would I want to learn EF? Honestly, I don't know. Feels like a waste of my time.
The dapper approach you displayed is not the latest. Here is the new approach using (var connection = My.ConnectionFactory()) { connection.Open(); var isSuccess = connection.Delete(new Invoice {InvoiceID = 1}); }
Thank you so much for pointing that out! I truly appreciate your update and apologize for the oversight. I will definitely use the latest approaches in the next video.
EF works with 1 record, but dapper work with list items which appropriate on condition (need select top 1 ... or update not all but one concrete), so it seems benchmark values on update, read, not correct.
Thank you for your valuable feedback! You’re absolutely right about the EF methods and the benchmark. I apologize for the mistake and will correct this in a follow-up video. Appreciate your insights!
In simple app EF looks very elegant, but too many times i have optimised slow EF application performance by writing same thing in raw sql. For EF to become slow you need a bigger database and work with data from dozen tables every time user presses a button.
For me the deciding factor is development speed, complex debugging as well as adding new tables, fields and relationships. EF clear "winner" for me. Love how EF simply takes care of much of stuff for you! Can always fine tune EF, throw in some stored procedures etc where needed. Heck even just beef up the Server! ;)
Benchmarking DB performance is always challenging. With our standard test before releases we seed a DB with a few million records, reindex and run the tests. We then compare the results with the previous release. EF caused us huge performance issues and trying to optimise queries with LINQ we found really hard. Switching to Dapper made a huge difference, sure you need to know SQL but this is good thing if you want performance and control. Other advantage is that Dapper can be used everywhere not just .net core applications.
Thank you for the detailed feedback! Benchmarking is indeed tricky. I'll work on improving my tests and share an updated video soon. Appreciate your insights on EF and Dapper!
I think it turned out to be a good piece of work, but I have a suggestion for you: please write the CRUD methods asynchronously, and let's see the results that way.
Hey friends, thanks so much for your feedback! 🙏
I wanted to address a few things 👇
Entity Framework: Some of you mentioned using ExecuteUpdateAsync and ExecuteDeleteAsync for updates and deletes. You’re right, and I should have included those to save a database trip. Sorry about that!
Dapper: There have been some updates to Dapper that I missed. Thanks for pointing these out! I’ll use the latest methods in my next video.
Benchmark: I know the benchmarking part wasn’t perfect. I’ll fix this in a follow-up video to make sure it’s accurate.
Thanks again for your support and helpful comments! I’m working on an updated video, so stay tuned! ❤
I'm an old SQL guy. As long as Dapper performs competitively then it will always be my choice. The big difference for me is stored procedures. I can write these in the comfort of SSMS and execute them easily in Dapper with no typos. Thank you Patrick!!!!
Thanks for your comment! Dapper and stored procedures are a powerful combo. Glad you found the video helpful!
When updating and deleting in EF, you should have used the ExecuteUpdateAsync and ExecuteDeleteAsync methods. This way, you don't have to first retrieve the record, saving you a trip to the database. Also, you could have just left out the benchmark part of this video since the results were not valid anyway to avoid confusion.
Thank you for your valuable feedback! You’re absolutely right about the EF methods and the benchmark. I apologize for the mistake and will correct this in a follow-up video. Appreciate your insights!
Nice to know that even gods make mistakes 😂. Nice video still m8
Dapper is my favorit for years. Besst tool ever.
Thanks for sharing! Dapper is indeed great for those who love control and performance. Glad to hear you like it!
EF is the way of doing a simple thing in the most complicated and least performing way
I would pick SQL over EF any day of the week. Why do I need EF? I know how to create a database, I know how to create tables, I know how to query data in those tables. It is a shame that this has become the default go to for data access in online tutorials etc. I have not been using .NET for a long time and coming from a more direct to SQL experience in the past I am discouraged whenever I check out a video and they start going on about EF, the normal result is I stop watching and find my information from another source. Which I have done many time on your videos. Rather than write SQL directly in the code, swap it out to a stored procedure and then you can debug and modify your SQL query without recompiling your code. As far as I know Dapper has no issue with stored procedures so win in my book. If I know SQL I can easily use Dapper so why would I want to learn EF? Honestly, I don't know. Feels like a waste of my time.
EF is good, but being an old-timer I prefer Dapper with stored procedures. It gives me more control and it's fast.
Thanks for sharing! Dapper with stored procedures is indeed powerful. It's great to have options depending on the need.
I use dapper because I'm comfortable using stored procedures. Plus the extra security on the database level with no direct access to the tables.
The dapper approach you displayed is not the latest.
Here is the new approach
using (var connection = My.ConnectionFactory())
{
connection.Open();
var isSuccess = connection.Delete(new Invoice {InvoiceID = 1});
}
Thank you so much for pointing that out! I truly appreciate your update and apologize for the oversight. I will definitely use the latest approaches in the next video.
EF works with 1 record, but dapper work with list items which appropriate on condition (need select top 1 ... or update not all but one concrete), so it seems benchmark values on update, read, not correct.
Thank you for your valuable feedback! You’re absolutely right about the EF methods and the benchmark. I apologize for the mistake and will correct this in a follow-up video. Appreciate your insights!
In simple app EF looks very elegant, but too many times i have optimised slow EF application performance by writing same thing in raw sql.
For EF to become slow you need a bigger database and work with data from dozen tables every time user presses a button.
Thanks for your input! You're right, EF can be slow with large databases. I’ll keep this in mind for future content.
For me the deciding factor is development speed, complex debugging as well as adding new tables, fields and relationships. EF clear "winner" for me. Love how EF simply takes care of much of stuff for you! Can always fine tune EF, throw in some stored procedures etc where needed. Heck even just beef up the Server! ;)
Benchmarking DB performance is always challenging. With our standard test before releases we seed a DB with a few million records, reindex and run the tests. We then compare the results with the previous release. EF caused us huge performance issues and trying to optimise queries with LINQ we found really hard. Switching to Dapper made a huge difference, sure you need to know SQL but this is good thing if you want performance and control. Other advantage is that Dapper can be used everywhere not just .net core applications.
Thank you for the detailed feedback! Benchmarking is indeed tricky. I'll work on improving my tests and share an updated video soon. Appreciate your insights on EF and Dapper!
Would using dapper be a good way to learn and experiment with SQL?
I think it turned out to be a good piece of work, but I have a suggestion for you: please write the CRUD methods asynchronously, and let's see the results that way.
Writing SQL code i very error prone, no syntax checking (it is just string), and refactoring is even more tedious. So my vote goes to EF
gracias
De nada! Gracias por ver el video.
Any repo related to this video?
I wish LINQ to DB was more popular..
Thanks for sharing! LINQ to DB is a great tool too. I might cover it in a future video.