AutoMapper - Custom Mapping

Up untill now we have gone various examples using AutoMapper that was doing one-to-one mapping. But there may arise some scenarios where we need to apply some custom logic for doing the mapping. We can do that in AutoMapper in multiple ways, one way of doing that is using ResolveUsing method while creating a map

AutoMapper - Ignoring Properties

In this post I will show you how to ignore properties from getting mapped automatically by AutoMapper. Suppose if both the source and destination has got a property with same name, but is used for representing different information, in that case we definitly not want the property to be mapped automatically. We can configure this while creating the mapping in AutoMapper as follows.

Syntax 

var config = new MapperConfiguration(cfg => { 
    cfg.CreateMap<Source, Destination>().ForMember(x =>x.DestinationPropertyName, opt => opt.Ignore());
});

Example

var config = new MapperConfiguration(cfg => { 
    cfg.CreateMap<Person, PersonVM>().ForMember(x =>x.Name, opt => opt.Ignore());
});

Since AutoMapper supports FluentAPI, you will be able to call ForMember methods multiple time if you ignore more than one property

var config = new MapperConfiguration(cfg => { 
cfg.CreateMap<Foo, FooCopy>()
.ForMember(x =>x.Name, opt => opt.Ignore())
.ForMember(x => x.Age , opt => opt.Ignore() );
});

In this example, while creating the mapping I have added the ForMember method to ignore the Name property while doing the mapping. If you look at the output window you can see that the value for Name is empty even though the property in the source instance has value in it

It will be a tedious procedure if we want to ignore a significant amount of properties from getting mapped automatically. So if you ever face that scenario do consider creating an extention class like the one below which ignores the properties based on data attribute specified in the model

Getting Started With AutoMapper

Automapper is an utility library designed for object-to-object mapping. Let's take the case of mapping columns in a data table to its equivalent business entity, we will have to manually write code for mapping each of these columns and assume if there are a lot of entities, it's quite boring as well as creates redundant code. Some bright minds in the industry took note of it and set to solve the problem by automating it and thus AutoMapper was born. 

First of all you need to install AutoMapper package, which can be done from the Package Manager Console using the following statement

PM> Install-Package AutoMapper

Let's create a simple program to do a basic mapping procedure.

1. Create a map which indicates the mapping flow for automapper.

var config = new MapperConfiguration(cfg => {
cfg.CreateMap<Source type, Destination type>();
});

IMapper mapper = config.CreateMapper(); 

  Suppose if you want to convert from class A to class B, then your mapping statement will be like 

var config = new MapperConfiguration(cfg => {
cfg.CreateMap<A, B>();
});

IMapper mapper = config.CreateMapper();

2. The actual mapping happens when we call the Mapper.Map function

var destinationObj =  mapper.Map<Source type>(Source instance);

Eg: var bObj = mapper.Map<A>(aObj);

Introduction to AutoMapper

In our daily life as developers, we sometimes do some sort of repetitive coding that can be avoided by some sort of automation. Automapper is one such utility which helps developers to mapping of properties from one object to another. Typical examples for this scenario includes mapping of Domain entity to a DTO(Data Transfer Objects) , Model to a ViewModel. Normally this sort of mapping occurs at the boundary between the layers where we need to transfer data, say from Data Layer to Business Layer or from Business Layer to Presentation Layer. 

In this example we have a class called Product which is a domain entity and we have another class called ProductViewModel which is a subset of the domain entity. So to transfer the data from the domain entity to the view model class we are manually mapping the properties one by one in line #17. The major drawbacks of these apporach are

Expression Bodied Members For Properties and Indexers in C# 6.0

In one of the earlier post blogged under new features in C# 6.0, we saw how we can make use of the Expression bodied functions to get rid of the one liner functions to increase the readability and maintainability of the code. Likewise we can also create expression bodied methods for properties instead of the classic getter method. For example let’s take a note of code given below which is using the classic way of creating and initializing the property.

Here we have a readonly property called FullName for which value is created by concactnating FirstName and LastName property in the getter method.

As you saw in the earlier post we can make use of the lambda arrow(=>) instead of the code block enclosed in curly braces({}) to define the body of the getter method. The syntax is pretty straightforward

property name => expression

Await in Catch and Finally Block in C# 6.0

In C# 5.0 Microsoft introduced asynchronous programming using the async and await keywords, but there was significant restriction for using await in catch and finally blocks. This was due to some specific issues in the compiler and with C# 6.0 they code in the compiler has undergone some changes to make it work. This was one of the most requested features from the developers worldwide because they resorted to write some complex logic in the catch block to overcome this restriction

Let’s take an example, in the earlier version if we write the code given below, we will get an compile error.

Expression Bodied Methods in C# 6.0

As developers we have created functions with a single statement that just return trivial values or expressions. Expression bodied function helps us to make our code more readable and concise. Normally we do write functions with statements being surrounded by curly braces be it for single line or for multiple lines of code. A typical example is given below

Working With Expando Objects

The ExpandoObject class was introduced in .NET 4.0 which allows you to set properties on to an object at runtime. It's part of the Dynamic Language Runtime(DLR) and resides in System.Dynamic namespace. With expando objects it's possible to add and remove members at runtime.

A typical use case for expando object usage is when we need to return multiple values from a method. It's possible to use a hash list or a dictionary object for achieving the same, but then you need to do some additional coding to retrieve the values in the caller method. With expando object we can easily access the info just like any other object instances.