So finally I have got a second piece of my earlier post. However this isn’t going to anything about Linq. We have already seen in part 1 how we can use Linq classes as data model classes. We have also seen how Automapper can help bind those data models to my view models in an MVC application. This post will be more about getting closer to real scenario where often your view model and data model are not always so similar that you can not get away with magic of Automapper without tweaking it. The goal of this post is to determine if Automapper is fast enough when mapping is complicated and when automapper has to be configured to map objects correctly.
For variety purposes this demo will be for a C# console application. I am using the new Visual Studio 2012 and .Net 4.5. I have also got Automapper as usual from my Nuget package manager. So here is how my data model and view model looks like. Take a peek.
You can see there are bunch of difference between view model and data model classes:
- The view model has string address while the data model has a seperate class CustomerAddressDataModel, it it is a member of CustomerDataModel
- The view model has CompleteName and data model has FirstName and LastName
- The view model has string IsMember while data model has boolean IsMember
- The view model has CustomerCode while data model does not have any such thing.
So here if you try to map the above data model and view model. Automapper will blow. It will fail because it does not know how to resolve these issues. I will give a little idea but will not get into too much detail about how to configure Automapper to do so. I will attach the source code with this post for an enthusiast to play with it.
The following code will configure my automapper to resolve the above mentioned differences and successfully map my data model to my view model (or list of those). I have used value resolvers to resolve the data type issue, create CustomerCode attribute for view model. I have mapped address string by combining various values from data model’s member class. One can also achevie the similar result by creating another value resolver for address. Similarly the FirstName and LastName are combined to do get CompleteName, super easy.
The test method is a generic test method. It does both Automapper mapping and Manual mapping and it does it for the specified count of data models. Currently it does one data model to view model mapping and prints on the console. You can see it maps correctly which means our configuration of Automapper is correct.
Till now we can conclude two things. Complex mapping can be achieved by Automapper. The mapping we did includes type casting, flattening, creating derived attributes. Also we see that it is about 0.048 seconds slower for one mapping, which is not a big deal, usually. Also I would like to point that Automapper always take a bit (in milliseconds) in first mapping more than its usual. Let’s compare as we did before, converting 100,000 data models to view models and see side by side comparision before we conclude any more.
So here we can see that for upto 1000 model mappings Automapper is not far behind and we hardly map more than 1000 models at one shot. What we see here is a very similar result to my part 1’s result of simple data model to view model mapping. This means Automapper has it’s consistency. Complex binding or simple binding, Automapper is a good tool to use and save time from mapping code, provided you can afford 100th second delay. Usually that’s not a problem Hence our goal: “determine if Automapper is fast enough when mapping is complicated and when Automapper has to be configured to map objects correctly” is accomplished and we can say that Automaper is great mapping and time saving tool.
It passes my tests, I hope it does your’s too. Take care.
Source Code (Visual studio 2012, .Net 4.5 solution. You might need to convert dlls if you are using other versions)