In my current role, we have come across a requirement to map message objects to more complex domain entities. As anyone that has done this previously will quickly tell you, manually writing code to do this is very boring and repetitive. With very limited time and resources, that effort could be better spent elsewhere on the project. As it seemed very simple to set up and start using we’ve decided to use AutoMapper.
Configuring / Using
Setting up a basic mapper is as simple as:
Mapper.CreateMap<Source,Target>(); var target = Mapper.Map<Source,Target>(source);
The call to CreateMap only needs to be made once for the duration of the AppDomain, calls to Map are then made as needed.
As was as direct property name mapping several other more complex mappings are provided “out of the box”. This includes flattening properties of child objects into named properties in the target object. AutoMapper also provides several different methods to provide custom mappings either inline in the form:
Mapper.CreateMap<CalendarEvent, CalendarEventForm>() .ForMember(dest => dest.EventDate, opt => opt.MapFrom(src => src.EventDate.Date)) .ForMember(dest => dest.EventHour, opt => opt.MapFrom(src => src.EventDate.Hour)) .ForMember(dest => dest.EventMinute, opt => opt.MapFrom(src => src.EventDate.Minute));
Or using custom formatting classes in the form:
Mapper.CreateMap<string, DateTime>().ConvertUsing(new DateTimeTypeConverter()); public class DateTimeTypeConverter : ITypeConverter<string, DateTime> { public DateTime Convert(string source) { return System.Convert.ToDateTime(source); } }
Performance
Initial tests have thrown up no surprises; the flexibility that Automapper provides does come with some overhead – but in most cases, I’m sure that the performance is going to be fine for the project in question. Being able to quickly map messages to domain objects and move on is going to improve the speed in which we can develop the project. If problems are encountered once the code base is live, there is nothing to stop the areas in question being re-investigated and/or rolled back to manual mappings.
As part of his fantastic ‘What is .NET standard‘ presentation at DDD12, Adam Ralph provided an amazing amount of detail in such a short amount of time. One of the most valuable points, which is completely obvious when you think about it, is how you should work with .NET standard when creating libraries. NET standard now comes in a multitude of flavours: currently 1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6 and 2.0. When starting out . . .
If you’re trying to access a class library (.NET Standard) from a traditional console application (in VS2017 those can be found under ‘Windows Classic Desktop’) you will run into problems; which can feel a little strange for something that was pretty simple in VS2015 and earlier. You can add a reference to the class library project (Resharper will even volunteer to add the dependency / namespace reference if you don’t already have it). But the . . .