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.
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.
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?
@@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.
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 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?
@@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
They seem to be in reverse order!
Great video, wish you a Happy Hanukkah! סיון רהב-מאיר
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. 😃
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.
Can we use the generic repository pattern like in EF core or do we have to write distinct queries for every entity?
Can someone give an example where the fields are not only strings?
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.
CancellationTokens are missing. Dapper lines should change a little bit to use CommandDefinition that takes cancellation tokens.
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?
Cool! Shouldn't we reuse the opened DB connection tho?
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?
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 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: th-cam.com/video/JiJeZOHx0ow/w-d-xo.html), but mssql can be set up in a similar fasion
@@amantinband Thank you!
Docker?
What vscode theme are you using?
Yep it’s the default
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
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
@santomy4579 I think they are talking about the IDbConnectionFactory at 6:30