The 3 Biggest Mistakes of Object Mapping in .NET

hello everybody I'm Nick and in this video I want to show you what I consider to be the three biggest mistakes of the process of object mapping in C sharp and no the first one is not don't use a library like Auto mapper I've already talked about that in a separate video you can check that out what I'm going to show you here is I'm going to assume you might be using a library or you might not be using a library to implement object mapping and then we're going to take it from there because these apply everywhere whether you're using a library or you're not if you like a lot of content and you want to see more make sure you subscribe and for more training check out my courses on domtrain.com and before I move on I'd like to let you know that I just launched my brand new course from Zero to Hero logging.net on donaldtrain.com now I'm extremely proud of this because login is such a fundamental of every dotnet application no matter what type of application is whether that's a desktop app an API a web app a game anything can have logging in it and it's also a cross-cutting concern meaning that it can actually cut through any type of layers that you might have in your application it is super important to have Mastery over it especially with modern tooling and this course achieves that we start from some very Basics assuming that you don't really know much about logging into some deep dives into some more advanced features and then we end up covering all of the advanced features and also some high performance features and then on top of that because I know how important it is and how much it is used I have a dedicated section on Siri log a third-party library for logging that most companies out there is using so you can have Mastery over that as well now to celebrate the launch I'm offering the first 400 of you a massive 20 discount code so go and check out and use log 20 to claim a 20 discount code at your purchase again that's for the first 400 of you and they do tend to go quickly so I hope you enjoy the course and now back to the video all right so let me show you what I have here I have a simple console application over here it doesn't really have anything we're going to be playing with these folders instead and I'm going to use them to demonstrate each example and the first one is injecting business logic into your mapper that is hands down one of the most dangerous ones because it is so easy to do let's take a look at this what I have here is this accounts folder and I have this account object so let's assume that this is sort of my domain object where I have the salutation the first name middle name last name email password and whether they opted in for communication or not and so on now that's not how I would model that account but I actually did find this online in a real application that's why I'm using it and then what I have here is a new account request so assume that this is coming from some API or from some web UI and I'm taking this new account request and I'm going to translate it into my account object over here now you can also assume that this object would be on the UI layer and this object would be on the domain replication layer the reason why I have them both in the same place is to make this easier to follow but assume that they also live in different projects so what you might have is if you're using Auto mapper a mapping profile like this now what I want to stress here is that this is a real mapper that existed in a project for years and I'm going to show you where I found this in a second but as you can see we map salutation to title then the rest have the same name then we ignore a couple of properties like the ID in the account type because they have default values and the remote communication opt-in into the agree newsletter because that's how business people work now I don't know if you can see this but there's a password map because the account object has a password as a string and then that parameter is actually using the text password one exclamation mod and then the date time now to set sort of the temporary default password for that user now besides the fact that this is largely dangerous and you should never ever ever deal with passwords like that this is also an example of hiding business logic into your mapper and in case you're wondering where I got this from it is an actual post for my real application in Reddit and the programming horror this was real now if even if you actually go and fix this if for example you go ahead and you say no I'm gonna use the random number generator here and say hey give me a hex string of 16 parameters in lowercase even if you do something like that this is still injecting business logic into your application your mapper should not know how to create passwords this is one of the biggest mistakes people make when it comes down to mappers because you will assume that this belongs here but it really really doesn't and some people don't like doing something like this so what they end up doing is actually they start injecting Services into the mapper so you might see something like an account service being injected in here and then because this account service has a generate default password method so I'm gonna say account service dot generate temporary password they're tempted to do something like this but this still violates the injection of business logic into your mapper this should not be in here do not do this even something as simple as this is very very dangerous when someone starts debugging the application and by the way this is something that's very hard to debug in the first place but when someone starts debugging the application they're gonna be like what the hell is this new password coming from and it's very hard to find the mapper not only that but it just does not belong here it is something that should be done into the account service I guess when you create that profile with the temporary password so rule number one stop injecting business logic into your mapper of any form and that actually especially with the injection over here leads into rule number two and it has to do with mocking now let's take a look at this one over here what I have is this account service now again dummy service but what is happening here is I'm injecting the eye mapper interface of automaper and this could be Iron mapper of any other library and then I have the mapping process here from my new account request to the account now we already established that this is bad because this mapping process has business logic in it I would also argue there is nothing also about what we just saw so why why the hell are you using a library anyway but what I'm trying to point out here is that we're injecting an eye mapper into this class so when the time comes to test this class you might be very tempted to do something like this we have the system under test which is the account service over here in our unit test and then you have a substitute or a mock for your eye mapper I've seen this a lot so people actually mock the eye mapper interface that is being injected into the class and then over here they say yeah for this map I'm actually going to go ahead and write the mapper manually which completely defeats the purpose of using an auto mapper or a mapping library in the first place the mapping process is part of what the method is doing what that unit that you're testing is doing you should never never ever have to mock your imapper what you should be doing instead is actually using the thing what is the value in you saying yeah this critical part of my application which in this case also has business this logic by the way I don't want to take any of that into account I'm gonna tell you what is going to happen and that's something unique just in the test what are you trying to achieve here take that mocking out remove it completely and load your profiles properly so if you need a mapper for your tests then simply say in this case because I'm using Auto mapper new mapper configuration and then say add profile new account mapping profile and then say create mapper and pass that mapper down the real thing you're going to get so much more value by actually using the real thing than by just removing it you're creating bad tests by doing something like that just do not and if you want to know more about unit testing I do have a course on Dom train and you know who else agrees Jimmy bogert the guy who actually made automapper now can we trust him because he did make automapper I'm gonna leave that to you but my opinion is for the love of God do not mock your mappers and you might say I need to mock my mapper because I'm injecting services into my mapper yeah that is your problem and you're exposing your problem by not mocking your mapper so that's the thing you want to deal with the mapper should be doing one very very clear job mapping from one object to the other that is it anything else outside of that is the responsibility of something else the last Point has to do with people trying to do manual mapping in what I consider to be the wrong way so let's take a look at this Spotify folder I have a Spotify album I've trimmed it down normally it's way way bigger and I have a Spotify album dto this is coming from the Spotify API and this is something I have in my application now usually because again these two things live in different layers the dto would live into the UI layer and the Spotify album would live into the domain layer in this case I'm not doing it to make the video easier to follow I've seen two things that I absolutely hate and I do not recommend to anyone the first one is if you want to create a Spotify album video for example out of the domain object then you might be tempted to do something like this you create a Constructor and and you say hey I have the Spotify album object why don't I create a Constructor where I pass the Spotify album object into the dto or the UI object basically and then I initialize everything here so you end up with a mapper like this now this has two problems the first one is well you cannot really do the opposite you cannot go to the Spotify album here and do the same if the two objects live in separate projects because you cannot have a circular dependency so you're gonna have to re-architect your solution to facilitate something like this which is bad but even if you could figure that out effectively in some way this is not something I would recommend to anyone because why should your dto or why should you domain objects know how to be constructed based on a different object which is not necessarily based on a domain concern but it is based on an architectural concern the fact that you have an album object or a dto object and you want to convert it into the domain why what's the value what is this class gaining out of this and this is not the only way I've seen this done the other way I've seen this done is like this people would go ahead and use an implicit or an explicit operator to hardcast or Auto cast from one type to the other and writer mapping logic in here why should this object know how to be converted to a dto it's a different thing to have sort of a value object that is like the Celsius temperature and that can be converted into a decimal or a double or float I don't know how you measure temperature but it's a different thing for that to have an implicit or explicit operator because that is a domain concern that makes sense and a different thing to try to cram architectural concerns into the same class on things that they just fundamentally shouldn't know what's the value of this object knowing how to be built from another object that is just a sister object that looks sort of the same but from a different concern it to me just does not make sense so what I recommend if you're gonna go with a manual mapper is just make a map to domain or map to DTR map to contract method extension method that is on the object and then you can have it in any layer you want usually you have an upstream sort of flow so each layer can have its own concerns with its own mappers and be done with it and if you need anything in your mapper just put it in here your objects don't have to know about any of that but now I want to know from you how do you feel about all these points and do you have any mistakes or pet peeves of your own when it comes to object mapping leave a comment down below and let me know well that's all I have for you guys video thank you very much for watching and as always keep coding

Channel: Nick Chapsas

Views: 36,049

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 7, The best .NET Mapper to use in 2023, automapper, mapster, .net mapper, .net object mapper, mapper, object mapper, mapperly, agilemapper, tinymapper, expressmapper, automapper vs mapster, automapper vs manual mapping, mapping mistakes, object mapping

Id: xPMlz9c2xIU

Length: 11min 32sec (692 seconds)

Published: Thu Jun 22 2023