Better Object Mapping in .NET with Dapper by Kevin Griffin

When people talk about using ORMs (Object Relational Mappers) like Entity Framework or nHibernate in their projects, often they are only looking for one fundamental feature: the ability to map SQL output to a C# object. Large ORM-based solutions add additional complexity, and black-box much of what is happening behind the scenes.
What if there was a smaller, more efficient way to do object mapping without the overhead of an EF? Dapper to the rescue! Dapper is a micro-ORM whose core function is to reduce some of the ceremony of talking to a SQL database while leaving you in complete control! In this session, we walk through many of the typical use-cases for Dapper and why you might want to consider it for your current or next project.
Agenda:
0:00 Introduction
2:07 What is Object Mapping?
6:02 Dapper
11:01 Scenario's and Demo's
25:38 QueryFirst or QueryFirstOrDefault
27:22 Insert/update/delete
31:55 Stored procedures
40:36 Questions and Answers
Slides and more: consultwithgri...
Join us:
ReSharper Website: jb.gg/yv6upa
ReSharper on Twitter: / resharper
Rider Website: jb.gg/8dplfh
Rider on Twitter: / jetbrainsrider
.NET Tools Blog: jb.gg/1kwpm6
About the Presenter:
Kevin Griffin is an author, teacher, mentor, and consultant focusing on software development. He is also a 10-time Microsoft MVP, specializing in ASP.NET and web development. As the owner of Swift Kick, a software training and services company, Kevin specializes in helping businesses push their technology stacks into the 21st century. You can often find Kevin speaking at conferences and user groups across the country or blogging at kevgriffin.com. In his spare time, Kevin is the co-host of the popular 2 Frugal Dudes podcast.
Twitter: / 1kevgriff
#JBDotNetDay #jetbrains #dapper #ORM
Categories: Webinar, Event

[@diManjenje88]

Started using dapper recently and the part about transactions was very good! Tks

[@kannagadu420]

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.

[@moofymoo]

Just imagine going to Hell and in first day Devil gives you codebase with EF and Dapper and informs that now you have to maintain this for ..eternity

[@berkanbilgin2287]

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

[@Aleksanderis]

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..

[@ConsultWithGriff]

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.

[@deanVetUk]

Thanks, excellent, appreciated. I much prefer dapper (and parameterized stored procedures) because we can see (and optimize) what's going on.

[@imadabab]

Me too.

[@markjsound]

You had me at: I'm not the biggest fan of entity framework

[@dandancast]

Thanks for the presentation PDF. Appreciate it. This is going to help my team to get started with Dapper.

[@thowheedh]

It is Illegal to use Visual Studio While Your Company Owns Rider

[@beckyTrendz]

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?

[@lgmsampaio]

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.

[@thepianist7379]

Great video, thank you, Kevin!

[@rosshoyt2030]

Nice talk!

[@ConsultWithGriff]

Thanks!

[@srinivasanjayamohan8177]

Thank you very much kevin.

[@brennanbugbee]

Thanks for this

[@powerToYourself36]

I can't emphasize how good this video is !

[@lgmsampaio]

In Feb 2022, Dapper async methods are not throwing exceptions when a SQL command fails.

[@Dunkhardt]

KEVIN!

[@MarcosIturribeitia]

Nice explanation thanks.

[@GenexMG]

Hi, is there any technology like Dynamic Data (.Net Framework) but for core or .net 5?

[@nero1988]

EF core for live. Dapper is for folks that are stuck on old way of doing things just need lite improvments

[@NabranAboubacar]

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

[@leftjabrighthook]

A lot of Dapper's methods have the same name, this should not be hard.

[@jaikrishnanr2731]

The title is misleading. It is just a beginner level.

[@LuigiZambetti]

Why you don't love much Entity Framework?

[@NeilTruick]

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...

[@gyanookharel7440]

"80% of your code is copied from StackOverflow" - Kevin Griffin, 2020

[@muhammadwaqasaziz4054]

I don't know why, BUT i like depper more, i don't like entity framework's black box.

[@SayWhaaaaaaaaaaaaaaaaaaaaaaat]

ENTITY FRAMEWORK IS WORST WHAT HAPPENED TO .NET

[@kayodebolarinwa653]

How?

[@charleswoodruff9013]

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.

[@arthurdent9281]

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.

[@lucasmontec]

"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.

[@arthurdent9281]

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?

[@lucasmontec]

@@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.

[@arthurdent9281]

@@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.

[@lucasmontec]

@@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.

[@arthurdent9281]

@@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.

[@NBGTFO]

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.