Entity Framework Core vs Dapper

so we're going to end up end up with nice little relaxing talk about different orm systems which is always a really easy conversation to have and no one ever really gets hung up about it and it's always a really stress-free conversation um and it never at all ends up looking a bit like um a bit like this um a bit of background and who i am um i i'm keith i'm one of the engineering managers at iris software group and i look after a product called cascade hr um which some of you may have um may have used at some point at bookie holidays um which is a mammoth 2.1 million lines of code enterprise monstrosity um with as usual every single coding language under the sun inside it um at iris we we've recently started a really good initiative of having internal lightning talks um and this is one that i gave towards the start of the year um certainly pre-covered um because there was some lively debate amongst various teams as to what the correct way of accessing data was and the reason this is quite contentious in our business is that we are that enterprise organization that literally still has uh visual basic six applications um we also have net core and we have everything else you know php and whatnot um but we do have a lot of teams trying to modernize uh in a hurry so in the next or ten minutes or so um i'm gonna go through the pros and cons of entity frame of using entity framework and dapper for accessing sql databases and i'm going to try and ignore kev um mouthing in the background use um i'm not going to touch on no sequel for this with those choices what we're really talking about is a choice between different strategies for accessing data or accessing relational data i know that technically dapper is not an orm but that didn't really fit on the meme so why do we do this at all why do we even have either of these systems the problem that in a way they are both trying to solve i think um is what you see on the left which is old-fashioned plain old ado.net why is this bad well it technically isn't it technically works it's been in the framework forever um but like there is a lot of it um i i still maintain code bases that i started writing back in 2005 and trying to find the business logic amongst the hundreds and hundreds of lines of this of creating new commands declaring parameters and so on um is tough and what tends to happen is that people say okay brilliant we are going to create a data access layer and that will move all the logic away um and in theory yes fine um but usually what you tend to find with those certainly in older code bases is that all the logic eventually ends up in the store procedures and that the net code is basically a glorified pipeline between the ui and the store procs and everyone just modifies the store procedures because you can patch those in production um rather than having to go through your release process so there are various strategies for making that easier making it easier more natural more productive to access data and we are going to compare two that are absolutely nothing alike and it is a totally unfair comparison we are comparing entity framework against dapper entity framework comes with concept of strongly typed data entities the concept of built-in migrations and tooling around that to do application upgrades and so on it comes with a link to sql that lets you do composable queries uh against your data strongly typed queries so that way you know you get intellisense you get compilation and all that good stuff you get change tracking and you get a unit of work so you can hook in events on when entities have changed you can do things like fire off domain events um it's easy to plug in things like auditing or at least it feels easy to plug in things like auditing and so on and so forth dapper it does query mapping and does parameter mapping and that's it um and yet i still think they are comparable so we're going to do a quick roundup of some of the good the bad and the ugly of each of these now we're going to start with entity framework if during this talk it sounds like i'm a little bit defensive about entity framework then it's because in a way i am i i have gone from being a huge advocate of it to not wanting to touch it with a barge pole um and in the last year or so actually coming back to it and thinking that you know what there is something there there are good parts and if used right it can it can actually be quite a good tool to use um so a lot of this talk uh ends up being well entity framework is bad parts but actually um so let's look at the bad parts um i've redacted some of the class names of this but if you've used a certain enterprise hr system then um this is a central part of that you've probably some of you would have seen um diagrams like this this is entity framework um database first when you reverse engineer an entity framework model from an existing database and generally speaking you end up with a mess because that database was not designed to be visually represented and usually when people have a big hate on for entity framework this is what they're thinking or they're thinking of this which is what it actually looks like at the back end huge great glob of xml um that everyone dreads having a merged conflict in because they're a nightmare sorted um and that leads to a lot of dislike for ef um and there are a few reasons for it an entity framework is quite often abused it's misused as a dumb data access layer which misses the point the database of foot i can talk the database first approach leads to those ugly great pdmx files that you've just seen um you can produce really bad queries with it if you don't know what you're doing and you can you can bring service to their knees um especially if you're abusing lazy loading or don't even know what lazy loading is or how it works and if i if i just say entity framework and to list um i guarantee there'll be some of you on here that know exactly what i mean uh and why that fixes everything breaks everything um it leads to a little bit of magical thinking because it's easy to type queries that compile uh without really thinking about how it works and that leads to bad stuff um how do you use it well um if i was using entity framework now on a greenfield app or a new module and i'd be looking at code first an entity framework core is very much a different beast from uh from ef6 and start from a code first approach you can define your models as plain old c-sharp objects you can define your models as rich entities as well and that's one of the things that's really come on um since older versions of entity framework previously um it was a bit like having objects that had to be serializable your properties had to be get settable which made them it it didn't really work well if you were trying to do a domain driven design approach um and control access to properties and fields and so on well you can you can now uh point entity framework to real domain objects you can map your fields to uh backing fields that's where you can map your database fields to backing fields you can control access to them you can map them to fields that aren't setable and you generally speaking you've got a lot more control you don't have to have fake navigation properties and so on and so forth um and you've got the joy of uh migrations um if this is going to work so um using code first you can build your uh your migrations up and then get those to run in your application um [Music] so that you can and there we go and you can use the lovely.net core command line tools to add migration either from scratch or between the previous state current state and those migrations are then programmatic they can be applied inside your application brilliant if you're creating applications there's like a blog for example where you're distributing something and someone wants to install it themselves and therefore it's got to manage its own its own schema um i've already said that that's that backing fields and how backing fields actually work um one of the ways i see entity framework abused and kind of devalued um is this um and please don't do this um this is essentially using entity framework as a dumb layer so what this is is someone saying i've got my business object and i'm going to map that through a repository and that's going to map to an entity framework entity and that's going to use entity framework to save the entity to the database really all you tend to accomplish there is mapping a load of business object fields to an entity that you then save you lose all the lovely stuff around change tracking and you still end up writing an awful lot of code uh to map fields from one to another and you end up with leaky abstractions usually through your repository um what do you do instead well your db context your data context that entity framework gives you is your repository if you use that as your repository layer and inject that throughout your application um you give yourself a lot more flexibility and you end up writing a hell of a lot less code and if you want to unit test it well you can test it you can use entity framework in memory providers and so on and so forth um so as a quick list of things to do uh or what i'd recommend doing if uh if i was looking at it i'd always use entity framework with my real business objects because he is for entities i would make use of the unit work patterns that it offers using db context as a repository which gives you all the lovely stuff around implicit transactions and so on and so forth definitely would not want to use it as a as a sort of weak dto layer so enough about entity framework let's have a look at dapper and the thing you'll notice about dapper if you haven't seen it already is that it is tiny um but what dapper does something very different is that it makes working with ado.net fun sort of if that's your idea of fun and i'm talking to devs who it probably is um it gets it stops you having to write all horrible boilerplate for creating db commands or sql commands [Music] and it lets you just map query to the result so you can map um a data set to a rich object and it will take care of the mapping back and forth and you can just pass in a anonymous object or even a rich object with your parameters in and it will map those parameters to the query there's a few more things it can map output parameters quite nicely there are some extensions that let you do um that let you sort that you compose queries um and give you some syntactic sugar around um getting getting more intelligence between your your c-sharp object your database will broadly this is all you really need to do with with dapper and what you get from it you get control so this is a chunk of code i wrote a few years ago and in this particular instance i needed to open a database transaction then do some work and get some data do some work in c sharp and then put some data back into sql um where you have a requirement like that dapper does a really good job of making sure the sql just gets out of your way so that your code is still readable you can you can see what the logic is um but it's it's you're still using the full power of ado.net you can create your transactions you can set your transaction level etc etc um and that was the thing that really got me hooked originally on on dapper you can do some other other good stuff um you can reduce your sprawl of dtos because dapper supports dynamic so you can run a query and you just get a list of dynamics back um to which you can you can read into objects or do whatever you like with um c sharp has a tendency to be quite sprawling when it comes to objects and this is a way to tame some of that um but again dapper does um very little maps data readers perhaps anonymous objects does a few little bits and bobs not much else what doesn't it do obviously quite a lot um if you do want to make use of a unit of work pattern you need to write your own or bring your own um [Music] you'll need to be writing your own abstractions um if you want to have a common uh data access object so you can put all your login in one place you're in charge of writing that go off and do it and you don't get the nice composable linked sql queries unless you want to write your own expression um trees and why would you you'd use entity framework um obviously things like change tracking again you're in charge of writing that um and migrations now dapper tends to assume your database has to assume that your database exists already and is managed separately so it's great if you've got an existing especially if you've got a very complex data structure that you need to interface with so in conclusion it's it's complicated [Music] there are trade-offs um again this is all my opinion um [Music] entity framework works really well if you've got a greenfield application if you've got the luxury of building brand new with a brand new schema it can be a really nice way of of working with data it works really well if your data schema is not necessarily small but simple if you have a fairly straightforward entity has a entity has many etc um it works well where you start getting into things like parent subcategories um to an extent one to ones and sort of more more ex more extreme on the normalization front it tends to feel a little bit more forced and then i you tend to find you're better off with with dapper um if you're doing domain driven design it can be good um you couldn't because you can write your your business objects map them straight into your db context um test coverage there is a um in-memory provider for um entity framework you can plug in it's not 100 uh the same as what you would get from sql and just because it works against that doesn't mean it's necessarily going to work when you hit an actual database um but it it does mean that you can get quite a high level of test coverage um and it's a hell of a lot nicer than trying to do mocks for linked sql um which is is a level of horror i do not want to participate in again um as i've said it's great if you've got to redistribute the lap and you get the nice unit of work pattern and transactions out of the box dapper works brilliantly when you've got an existing database or if you're creating a little module that sort of hangs off an existing system dapper is great for that if the scheme is particularly complex yep dapper will handle it because all it's doing is just mapping whatever your query brings back to a.net object if transactions are key and they are complicated and you need to set lots of different levels of them and and you really need fine control of when you roll back etc that was a good choice um ditto using the more advanced sql features that might be a bit more challenging to implement in ef um if you're still procedure heavy um if your database is a bit more old-fashioned yep that dapper's got you covered um and if your data access is a bit more ad hoc um and a bit less entity focused then then again dapper's probably the best for you and that's me and thanks for bearing with

Channel: dotnetsheff

Views: 4,595

Rating: 4.8909092 out of 5

Keywords: EF, Entity Framework, Dapper, C#, .NET

Id: jtEBoF4lQJA

Length: 19min 7sec (1147 seconds)

Published: Mon Sep 07 2020