Talk itself was nice, but I would say its' title is misleading. It was more like "introduction to Dapper" (and quite beginner level), rather than "doing something better with it". Eventhough it can be really useful talk who wants to know about "alternative" ORM, but I was hoping I would get something more advanced about Dapper looking at how talk is titled..
Apologies for not meeting your expectations. The high majority of people attending this talk have never used Dapper before and would be lost in a higher-level discussion.
I mix both EF and dapper. Using EF for code first and DbUp for applying the migrations and EF for easy selects with filters and aggregations and dapper for large tables and complex database requests.
Thats exactly what i thought.. it could be segrated as a repository itself, and wouldnt be hard to manage. Performance critical queries are great candidate for dapper. Cant wait to use it
Thanks Kevin What if I create a model that has all the columns in the person table and have same query, how do I narrow my query to display only my specified columns of my sql statement?
Geezz.. you lost me in the Store Procedure part. Store procedures are a nightmare that I never wanna have to deal with again. Debugging, code versioning, etc. Don't let me start.
Dope! But i'm in a situation where using SQL Helper from microsoft since 2005, in big 3 layer system. Classes are stored in a BL library A way to replace Sql Helper with dapper smoothly ? Regards
Oh, where do I begin? It is not a nice ORM at all. Configuring it is a nightmare, even with CodeFirst. The queries it builds are absolutely cryptic. I was a huge LINQ-to-SQL fan for the longest time, even when Microsoft insisted we use Entity Framework, despite it being buggy and non-performant. LINQ-to-SQL was so close to being the answer. There were a few wrinkles they _wouldn't_ figure out, like a decent many-to-many implementation. The SQL it wrote was legible and made sense. If you have experience with any other non-Microsoft ORM (like SqlAlchemy for Python), you're asking yourself why did Microsoft take so long to figure this out? 14 years and they JUST figured many-to-many? Oh, please...
What's the point of demoing how to do things the WRONG way? If the model should be created somewhere else and services should be injected, then DEMO THAT. It's like teaching someone how to drive, but your seat belt is unfastened and you're drinking from a bottle of whiskey while telling them not to do that. It's irritating to see developers demo bad coding practices for convenience.
Because it keeps examples simple and focused on what he's teaching, rather than on aspects of development that are not the subject of the talk. Demonstrating how to build a production-ready app is not the goal here, and would simply take more time while not adding anything about the topic he's trying to teach.
"you know how to create you own database" - Even if I did, why would I do it? The idea is to avoid exactly that! SQL is a very very very complex and unintuitive language.
Developers should have a solid understanding of how to build and use a database. Otherwise you're putting it in the hands of tools whose functionality you don't understand. Did those tools make the right choices? How would you know? How would you fix it if there's a problem?
@@arthurdent9281 you know full stack developers don't exist right? You know people work in teams right? You know you don't have to be fluent with a technology to use it and to be able to interface with someone that is an expert right? Also, the entire argumentation is around the fact that sql is bad, so it doesn't matter what one knows. Also, most SQL abstractions do fine for 90% of the cases.
@@lucasmontec If you're responsible for writing db code, whether it's with a tool or not, you're responsible for understanding how it works, which means understanding how the database works as well. It's that simple.
@@arthurdent9281 yeah, it depends actually. Depends on what application you are working on, the scope of the DB usage, the value and sensitivity of the data...it is quite not that simple. Yeah, a DBA should know SQL, yet there are different stages and types of applications. This is a generalist tool so it is not the best assumption.
@@lucasmontec Yes, it does depend on those things, and whoever is writing the DB code should understand those constraints and how to deal with them. If a DBA is responsible for it, then they should be writing, or at least reviewing the code, as they would be the one responsible for ensuring that it meets requirements and performance standards and dealing with any issues related to it.
I understand that not all people like all things, but poo-pooing something just because you don't want to take the time to fully learn a thing before being able to use it effectively sounds lazy. EF is an awesome tech and while not perfect (absolutely nothing is), its capabilities are incrediable and you do yourself and everyone else a great disservice by dismissing it. That makes everything else you say here questionable so I won't bother watching the whole thing. If you can't be objective, you're of no use to anyone.