"Stop Using Automapper in .NET!" - Code Cop #001

hello everybody I'm Nick and this is the very first episode of a brand new series called LinkedIn advice Police Department or LAPD now if you're using LinkedIn you probably have seen many people posting pictures of tips and tricks for clean code and c-sharp and best practices and so on now the vast majority of this advice is absolutely terrible and what I want to do in this series is take some of that advice and try to learn something from it by correcting it none of this is a personal attack to the person who created the post I'm going to be showcasing in fact everything is anonymized this is just me trying to actually teach you something based on some really really bad advice the main reason for that is because the LinkedIn algorithm will promote anything no matter if it's good or bad and I want to prevent you from making mistakes by looking at those posts and thinking that because they have many likes they're also correct it's a level of content and you want to see more make sure you subscribe for more training check out my courses on dumbtrain.com now before I move on I'd like to let you know we just launched a brand new course on dome train call from Zero to Hero Docker for Developers Docker is still the most used tool in the developer ecosystem and is a must know for everybody this course is very up-to-date it teaches you everything you need to know about Docker from the very Basics how to install it and how to get started with it to some pretty advanced stuff in terms of security and tips and tricks and this authored by Dan Clark a new author on Dom train he has been working with Docker for years and he's seen that Good the Bad and the Ugly and this course is going to teach you everything you need to know to use it the right way with the best practices and use it as one of the most valuable Tools in your toolbox even if you do know how to work with Docker on a basic level this course will teach you literally everything you need to know as a developer and it's made with developers in mind now to celebrate the launch I'd like to offer the first 400 of you a 15 discount code on your purchase so click the link description and use the discount code you see right now in your screen to claim your discount now back to the video okay so let's take a look at this post which is actually pretty aggressive the advice is do not use automobile and use tiny mopper instead now why do I absolutely hate this post well first this is a slide so so we'll be going through multiple slides that this post had the first one is this the truth the facts what I'm saying is correct in spite of the fact that automapper is too heavy and slow which is also misspelled a lot of developers are using it why and then there's a benchmark and this is the biggest issue I have with this post because in that post there is no context in terms of the code used to run this Benchmark nowhere this could be anywhere the code for this could be terrible so how can you trust this you can't Auto mapper here is shown to be 4.8 seconds while tiny mapper is 80 milliseconds and handmade mopper is 21 milliseconds now I've made a video a while back comparing every mapper that is not dead and Tiny mapper is basically that nobody's really maintaining it and my results vary quite a bit I'm going to show you those results at the end but when you see advice like this always try to find the source and review the code you can't just take any of this for granted oral's gospel trust me bro mentality in a lot of this and never trusted even from people who you know including myself take my code review it and run it yourself then there's a getting started with tiny mapper here I'm going to show you another object mapper Library which is 100 times faster than automaper time mopper now you can see how you can do mapping and the reason why this is horrible is because this static binding over here should only happen once you don't want to have this bind method called every time you want to map a person because that's the static configuration put it somewhere call it once a startup and that is it I think the author tried to actually Point towards that by saying that note if you're multi-threading an application register all bindings your application start and then just call the map method then why do you show this as something that you can do in non-multi threading scenarios you shouldn't they should always be called at the startup application multi-threading or not never ever ever call bind and then map as part of the same method now these are the numbers you see over here with tiny mumper Auto mapper and handmade however my numbers from six months ago are quite different in fact my manual mapper over here is the fastest and then maperley is the second fastest which is uh so generated then you have mobster then you have mapping generator which is another code generation tool then you have Auto mapper which is seven times slower than manual mapper and then you have tiny mapper which is 15 times slower than the manual mapper twice as memory inefficient and twice as slow as automapper so what is this even supposed to be representing nothing it is bad advice that is horrible never ever ever believe anything that has benchmarks without actually reviewing it yourself this advice is pure garbage the next advice I want to showcase is middleware related however it doesn't have to do necessarily with the middleware itself so what we have here is middleware and C sharp here's an example of middleware and what is not shown here is you can actually also implement the eye milware interface so you don't have to use duct typing to create your middleware but this would also work however as I can see over here there is no await keyword for the writing the response and this can cause some terrible terrible problems so always avoid these async calls over here especially when you're writing the response but my biggest issue isn't with this line over here rather with the registration of the middleware itself here we have two issues the first one is a minor one the use method is used to register the middleware and you can actually do that if I go over here and I say app don't use then I can have a new middleware and I can pick like the static file middleware over here and red summer middleware in that way and that is fine however the command the pros with littleware like this is actually the way simpler app dot use middleware and then pass your middleware as a parameter like this so you don't have to worry about newing up any objects or anything like that it will be done automatically for you and not only that dependency injection will also be taken care of which is really the main issue we have here you see here we have a new HTTP client which is really really really problematic now you don't need to know by heart whether this use method will register this middleware as scoped as transient or as a Singleton no matter which approach will be used here this is wrong because the HTTP client will either be created every time pay request which is bad because it will lead to socket exhaustion or it will be only one throughout the application lifetime which can cause a DNS issue where the DNS does not change because the HTTP client is not renewed at any point when you're using HTTP client especially when you're injecting it you want to use the ihdp client Factory and inject that into your middleware instead or any other class never new up the HTTP client manually the ihtp client Factory will pull the handlers behind the scenes and renew the clients to guarantee that you don't have socket exhaustion and that you do not have any DNS issues this advice is bad again missing and await no point towards the interface of middleware which is not a biggie but this one is terrible also there is not really any more a startup class so this is also a bit outdated the last Point has to do with naming objects and naming is very tricky in general however this is more of a personal opinion on the matter so if you disagree with me just leave a comment down below but it says that you should not name parameters like this so s for student or STD NT for student or student list for student list now I don't necessarily think that the student list is a bad name because yes this is a list and if the list aspect of it is important for the app then why not name it like this if it was an innumerable I would be more okay with naming it as students and not student list but I can see why this could be bad but I can't see however is this one over here students don't wear because using a single letter like s is in my opinion totally fine if what you're dealing with is absolutely obvious in this case students there's no question if what I'm using in here is a student or not because I can see it so I will be expanding my code horizontally for absolutely no reason by naming this student and what if the name was longer it will be really really hard to work with link which is already nested by Nature making my code really really bad so I do agree with student I do agree with students but I would never never in this scenario with link use the full name of the parameter in here I would use x personally because for some reason that's what I like to use or XX or Y or S if you want to use the first letter of the students but I will never use the full name now this changes in situations where the type here is not obvious for example if I go on Startup and I say app dot use well I would never use x here because the type of what x is isn't obvious based on what's coming before it so this would be the request delegate or it could be the HTTP context so context and request delegate but this is also because it's very likely you're going to be doing some complicated work in here anyway and you want to know what's in every type of delegate and the context it's not as simple as saying do this everywhere and do this everywhere so this advice is bad because it tries to generalize things that should not be generalized without giving any context now these are the three things I wanted to mention in this video and as always I want to know what you think so please leave a comment down below letting me know if you agree with my advice and my points if not and I'd really like to know your opinions as well in the comments down below well that's all I have for you first video thank you very much for watching and as always keep coding

Channel: Nick Chapsas

Views: 86,529

Keywords: Elfocrash, elfo, coding, .netcore, dot net, core, C#, how to code, tutorial, development, software engineering, microsoft, microsoft mvp, .net core, nick chapsas, chapsas, dotnet, .net, .net 8, lapd, linkedin advice, linkedin advice police department, lapd nick, linkedin advice nick, linkedin advice dotnet, linkedin advice c#, don't use automapper, use automapper, automapper, mapster, mapperly

Id: utt-5J9PN3Q

Length: 9min 56sec (596 seconds)

Published: Mon Sep 18 2023