Thanks for the video but I actually don't want to find myself writing sql queries on the code side. Sometimes I can add a new feature to a class and then I need to change or update the sql query that I defined as dapper query in my repository. btw I know the dapper's power.
4:45 Best practice/Performance tip: return a boolean or an Error object instead of throwing an exception. For methods that return valid values, such as GetByIdAsync, you can use OneOf or ErrorOr libraries to return an explicit "not found" instead of using null as an implicit case.
I haven’t used Dapper in 15 years, it’s barely changed, it certainly isn’t a EF CORE killer, but is worth knowing for the few scenarios it does a better job than EF CORE
Thanks very much Amichai for this video. I'd like you make video how is your vscode settings, add-ons, settings, tips e etc. I notice that your vscode look like vim editor. Again, thank you.
@@PatricSjoeoe I did some speed tests last year, and had the same conclusion. However, when working on a bad database, you might still prefer to use raw sql over objects. No significant difference in memory usage or things like that.
Hi, Amichai. Thanks for the video. Can you say please is it would be a good idea to change our insert and select queries using string interpolation for naming columns using nameof(Product.Name) for example instead of hardcoding column titles in query string?
Thanks for the video. In the work environment, do you use postgre SQL or MSSQL? I ask it because in macOS you cannot use the MSSQL. I wonder how do you handle it?
Sorry, but Dapper went out of fashion 15 years ago. And so did the bad practice of writing non-parameterised raw SQL into code. EF provides a much better way of doing things.
@@jcorrify I don't think any of my clients would thank me for imposing 15 year out of date tech debt on them. Good luck with doing that to your clients!
@@ddrsdiego I have no issue with using primary constructors. I hate mapping DI parameters to corresponding private fields. Only thing they should fix is making the parameters read-only.
Please add numbers to the title of the videos. i clicked on the playlist link and it's a bit confusing in what order i should watch them
Thanks for the video but I actually don't want to find myself writing sql queries on the code side. Sometimes I can add a new feature to a class and then I need to change or update the sql query that I defined as dapper query in my repository. btw I know the dapper's power.
Noob
skill issue )
4:45 Best practice/Performance tip: return a boolean or an Error object instead of throwing an exception. For methods that return valid values, such as GetByIdAsync, you can use OneOf or ErrorOr libraries to return an explicit "not found" instead of using null as an implicit case.
I would likely recommend yes throwing. In most cases, this should be truly unexpected and should be treated as such.
Not sure you realise Amichai is the author of the mentioned ErrorOr Nuget.... I'm confident he knows what he does...
Really good video, learnt some things I didn't know here (I'm not a dev), but now thinking of how I can apply this to my own projects. 😃
I haven’t used Dapper in 15 years, it’s barely changed, it certainly isn’t a EF CORE killer, but is worth knowing for the few scenarios it does a better job than EF CORE
Why would it need to change?
Thanks very much Amichai for this video.
I'd like you make video how is your vscode settings, add-ons, settings, tips e etc. I notice that your vscode look like vim editor. Again, thank you.
Great video as always. One question I have is why did we go with Dapper instead of EF?
Just to mix things up. Both are great options for prod and non-prod apps with different pros and cons
EF Core getting better and better, Dapper is now obsolete.
@@PatricSjoeoe I did some speed tests last year, and had the same conclusion.
However, when working on a bad database, you might still prefer to use raw sql over objects.
No significant difference in memory usage or things like that.
@@PatricSjoeoe Great video but with the recent developments of EF Dapper it is no longer as beneficial as before.
why scoped for IDBConnectionFactory class?
Can we use the generic repository pattern like in EF core or do we have to write distinct queries for every entity?
Cool! Shouldn't we reuse the opened DB connection tho?
Hi, Amichai. Thanks for the video.
Can you say please is it would be a good idea to change our insert and select queries using string interpolation for naming columns using nameof(Product.Name) for example instead of hardcoding column titles in query string?
I have been seeing singular names for repositories out there, like "ProductRepository" instead of "ProductsRepository". Which makes more sense?
Both
I usually try to not use plural for words that should work as an adjective. But i am not a native speaker.
Thanks for the video.
In the work environment, do you use postgre SQL or MSSQL? I ask it because in macOS you cannot use the MSSQL. I wonder how do you handle it?
In this series I'm using postgres (as part of this video: ruclips.net/video/JiJeZOHx0ow/видео.html), but mssql can be set up in a similar fasion
@@amantinband Thank you!
Docker?
I think you should be AddSingleton instead AddScoped, correct me if I'm wrong
Great video but with the recent developments of EF Dapper it is no longer as beneficial as before.
Right, although sometimes the choice is a matter of personal preferences and not only performance
If u want to have an immutable model is hard to do with ef core compared to dapper
Sorry, but Dapper went out of fashion 15 years ago. And so did the bad practice of writing non-parameterised raw SQL into code.
EF provides a much better way of doing things.
The queries are actually parameterized... Dapper or EF is a matter of preference... If you don't like, don't use it but it's still a good option
@@jcorrify I don't think any of my clients would thank me for imposing 15 year out of date tech debt on them. Good luck with doing that to your clients!
What vscode theme are you using?
It’s the default theme
Yep it’s the default
Why the heck are you using primary constructors and assigning a private field variable? Just use the parameter directly. Thats the point of it
Do better, don't use primary constructors
@@ddrsdiego I have no issue with using primary constructors. I hate mapping DI parameters to corresponding private fields. Only thing they should fix is making the parameters read-only.
Can you please elaborate on which point you are referring to by timestamp.
@@santomy4579 E.g 6:39 and 8:10