Automapper for .NET Core

Eat Sleep Code Podcast

On this episode of Eat Sleep Code guest Jimmy Bogard shares his perspective on Microsoft's basic object-mapper. Jimmy talks about the future of Automapper and support for .NET Core & .NET Standard. 00:57 EC: So I wanted to get you on the show today, because of a GitHub issue I saw on the MVC GitHub repository. And this GitHub issue is… It reads, “Basic object mapper for simple model view. View model property mapping.” And I have a feeling that you have some opinions about this, having one of… A very popular NuGet package for ‘.NET’ AutoMapper. And it’s been quite successful. And this, to me, it looks like it may step on your toes a little bit. So I wanted to get you to talk about kinda where you’re at and how this affects you. But before we get started, why don’t you give everybody a quick introduction of who you are and what you do, Jimmy? 01:56 JB: Okay. I guess I really write code for customers for a living. I work at a consulting company called Headspring out of Austin, Texas. And nearly all of the open-source stuff I work on, is just stuff that I build to help my clients. It’s just tools I wanted to keep using, and using, and using as we go from client to client. And so, almost everything that I write and use these days with open-source is stuff I’m actually using on client projects, that I don’t wanna lose when I go to the next client. 02:33 EC: And you have this tool called AutoMapper, which is an object mapping tool. Why don’t we give everybody a quick elevator pitch. What is an object mapper? 02:46 JB: Well, the basic idea is I have two objects that look pretty similar, and my general use case was I’m building web applications in ASP.NET MVC, typically. And I have a rich domain model that’s bound to the database in some way or another, usually with an ORM, like in any framework. But then, I had this other thing I’m using to show information on the web, either for showing forms, or also posting data from the web. And you have this general problem, and that’s your backend object is generally very rich and behavioral, and has a lot of things associated with it, but the thing you’re coming in from the web, is generally not. And you typically don’t wanna mix those two things together. So about… Gosh, eight or nine years ago, I saw this issue of when we’re starting out MVC, that we wanted to have these DTOs that we use for the MVC side and have these rich backend objects. But what would be the mechanism that we copy that information from the rich backend objects to the frontend dumb DTO objects? And I didn’t wanna do that all by hand, and I looked around, and saw there really wasn’t anything that did it for you automatically. And so, I created AutoMapper as a way to automatically figure out how to copy information from one object to the other. 04:12 JB: Probably a stupid idea. That didn’t seem that complicated, but there were a few things that I wanted to have out of the box that would help us out. One of the big ones was flattening, so if you have “foo.bar.baz” on your destination object, you could just have a single property, “foo, bar, baz.” And it would automatically traverse those associations, and figure out how to flatten that object for you. It handled nulls as well. If foo was null or bar was null, it’d be able to handle that as well. And the other big thing that I wanted to do, was make sure we could test it as well. So if I misspelled something or removed a property, I could just have one line of… Just check all my configuration is valid, and all the names match up, and there’s nothing missing. And if there is, go in exception, so it’s really easy for us to test, to say, “Make sure all my mappings are good.” Find out more at http://developer.telerik.com/content-types/podcast/automapper-net-core/