Nice video Patrick, one thing I'm a little confused about is why you chose to use the System.Data.SqlClient over the Microsoft.Data.SqlClient. I was led to believe the Microsoft version is the latest and greatest going forward ?
Yep, my bad. Sorry about that. That's a classic "we always did it that way". 😳 You can, and probably should, use Microsoft.Data.SqlClient - BUT then you have to make sure to use "TrustServerCertificate=true" in your connection sting. Otherwise you'll get an exception. Cheers!
That's a bold claim Patrick, "Imagine you just got a new job and assigned databases, you most likely be using Dapper..." With the stack you presented, MSSQL and .NET, I would make a bet that 6 out of 10 developers would probably be using EF. Don't get me wrong, I love and quite often use dapper for quick projects, but EF is probably the go to choice for this stack Anyways, great content and keep it up, video was great and very educational for someone wanting to get their feet wet with Dapper. ❤
Thanks for your feedback! I'm totally with you. It's just that many devs seem to be using Dapper even for that stack, in particular when the database already exists - and for performance reasons. The equivalent Entity Framework video is coming soon. 😉
Nice video PG, I am curious to know that what if we want to do db with code first approach with migrations, does Dapper support that, or Dapper is for doing just the CRUD operations?
As far as I know, there is no code-first approach with Dapper. Except, there seems to be something similar with Dapper Plus. The other option would be to use Entity Framework for code-first migrations and then use Dapper for your CRUD operations. Hope this helps!
Great intro to Dapper. I just don’t know if I should use Dapper or EF Core. I have an old monolithic system with 315 tables and 1200 stored procedures. I have the old fashioned CRUD stored procedures that I really want to keep on using.
The problem with modern SW development is: someone creates a lib/technology XYZ for some special use case where it might be reasonable as the mainstream libs/technologies do not yet cover some features. Then other people see it and use it as well - but often in situations where it is NOT reasonable, useless or even harmful. A typical example are NoSQL DBs which are in 90% of the cases a worse choice compared to a goody old style, boring relational DBs (e.g. postgres). "but MongoDB is such a cool and hip trend product". Later these people move on and someone else has to cleanup the mass they left behind. Dapper is maybe in some cases 10% faster as EF. But the effort is MUCH higher and not using the "fail at compile time" features of LINQ is careless. I promise you in 10 years many companies will have to clean up the mass the Python hype has left behind, just like they have to clean up the mass PHP hype has left behind.
Another awesome video! Thank you Patrick!! I would love to see a video using stored procedures to perform the CRUD operations with Dapper
Nice video Patrick, one thing I'm a little confused about is why you chose to use the System.Data.SqlClient over the Microsoft.Data.SqlClient. I was led to believe the Microsoft version is the latest and greatest going forward ?
Yep, my bad. Sorry about that. That's a classic "we always did it that way". 😳 You can, and probably should, use Microsoft.Data.SqlClient - BUT then you have to make sure to use "TrustServerCertificate=true" in your connection sting. Otherwise you'll get an exception. Cheers!
Greate Video ! Thank you that is my first time use dapper in my projects you explained it very well
Thanks a lot for your feedback! Appreciate it. ☺️
More work involved but well worth it for the speed and flexibility gains over EF.
That's a bold claim Patrick, "Imagine you just got a new job and assigned databases, you most likely be using Dapper..." With the stack you presented, MSSQL and .NET, I would make a bet that 6 out of 10 developers would probably be using EF.
Don't get me wrong, I love and quite often use dapper for quick projects, but EF is probably the go to choice for this stack
Anyways, great content and keep it up, video was great and very educational for someone wanting to get their feet wet with Dapper. ❤
Thanks for your feedback! I'm totally with you. It's just that many devs seem to be using Dapper even for that stack, in particular when the database already exists - and for performance reasons. The equivalent Entity Framework video is coming soon. 😉
In commercial projects that use CQRS it is often the case that EF is used to build commands and Dapper is used to build queries.
Thank you very useful video!!!
Nice video PG, I am curious to know that what if we want to do db with code first approach with migrations, does Dapper support that, or Dapper is for doing just the CRUD operations?
As far as I know, there is no code-first approach with Dapper. Except, there seems to be something similar with Dapper Plus. The other option would be to use Entity Framework for code-first migrations and then use Dapper for your CRUD operations. Hope this helps!
very good video , thank you
Great intro to Dapper. I just don’t know if I should use Dapper or EF Core. I have an old monolithic system with 315 tables and 1200 stored procedures. I have the old fashioned CRUD stored procedures that I really want to keep on using.
i'd use Dapper in this case
Dapper
What is the icon that pops up when you edit JSON in Swagger? Is it a Chrome extension?
Yep, it's the Grammarly extension.
The problem with modern SW development is: someone creates a lib/technology XYZ for some special use case where it might be reasonable as the mainstream libs/technologies do not yet cover some features. Then other people see it and use it as well - but often in situations where it is NOT reasonable, useless or even harmful. A typical example are NoSQL DBs which are in 90% of the cases a worse choice compared to a goody old style, boring relational DBs (e.g. postgres). "but MongoDB is such a cool and hip trend product". Later these people move on and someone else has to cleanup the mass they left behind. Dapper is maybe in some cases 10% faster as EF. But the effort is MUCH higher and not using the "fail at compile time" features of LINQ is careless. I promise you in 10 years many companies will have to clean up the mass the Python hype has left behind, just like they have to clean up the mass PHP hype has left behind.