Select method is used to project each element of a sequence into a new form, i.e. it can be used to map a collection of one type to a collection of another type. In this article I’ll show you a simple approach that will allow you to reuse the code used in the Select method.
Table of contents
- The problem
- Solution 1 – Creating a method for the mapping
- Solution 2 – Creating a generic ObjectMapper object
- Final thoughts
- References
- Downloads
The Problem
Consider the following model:
Let’s suppose that you have a services layer, so you don’t want to expose your domain objects directly to the client applications. Instead you create a set of data contracts (or DTOs, if you prefer):
At some stage you’ll have to convert those Domain objects to data contracts. This is a common way of doing it:
var details = repository.All<Album>().Select(album => new AlbumDetail { AlbumId = album.AlbumId, Price = album.Price, Title = album.Title, ArtistId = album.ArtistId, GenreId = album.GenreId, ArtistName = (album.Artist == null) ? null : album.Artist.Name, GenreName = (album.Genre == null) ? null : album.Genre.Name });
There is a problem with this approach – if you need to query the same collection but using different criteria you have to duplicate the code inside the Select method.
Solution 1 – Creating a method for the mapping
In order to reuse the code, we can create a method that converts Album objects (Domain) to data contract objects:
private static AlbumSummary CreateAlbumSummary(Album album) { return new AlbumSummary { AlbumId = album.AlbumId, Title = album.Title, ArtistName = (album.Artist == null) ? null : album.Artist.Name }; } private static AlbumDetail CreateAlbumDetail(Album album) { return new AlbumDetail { AlbumId = album.AlbumId, Price = album.Price, Title = album.Title, ArtistId = album.ArtistId, GenreId = album.GenreId, ArtistName = (album.Artist == null) ? null : album.Artist.Name, GenreName = (album.Genre == null) ? null : album.Genre.Name }; }
Using the code:
var albums = Albums.Select(CreateAlbumDetail); var albumsByGenre = Albums.Where(x => x.GenreId == genreId).Select(CreateAlbumDetail); // alternative way var albums2 = Albums.Select(x => CreateAlbumDetail(x)); var albumsByGenre2 = Albums.Where(x => x.GenreId == genreId).Select(x => CreateAlbumDetail(x));
Solution 2 – Creating a generic ObjectMapper object
The previous solution solves the code reusability problem, but there’s still a tight coupling between components. Abstractions should be used to implement loose coupling between components – in this case, to abstract the mapping code.
Step 1: define a contract (interface) with a method that converts one object of type TSource to an object of type TDestination:
public interface IObjectMapper { TDestination Map<TSource, TDestination>(TSource source); }
Step 2: create a class that implements IObjectMapper (click to expand):
public class ObjectMapper : IObjectMapper { private Dictionary<Type, Func<object, object>> Mappers = new Dictionary<Type, Func<object, object>> { { typeof(Tuple<Album, AlbumDetail>), CreateAlbumDetail }, { typeof(Tuple<Album, AlbumSummary>), CreateAlbumSummary } // more mappings here // .... }; public TDestination Map<TSource, TDestination>(TSource source) { if(source == null) return default(TDestination); Func<object, object> mapper = null; Type key = typeof(Tuple<TSource, TDestination>); if(Mappers.TryGetValue(key, out mapper)) { var newObject = mapper(source); return (TDestination) newObject; } string errorMessage = string.Format("Invalid mapping (Source: {0}, Destination: {1})";, typeof(TSource).FullName, typeof(TDestination).FullName); throw new InvalidOperationException(errorMessage); } private static object CreateAlbumDetail(object source) { var album = source as Album; return new AlbumDetail { AlbumId = album.AlbumId, Price = album.Price, Title = album.Title, ArtistId = album.ArtistId, GenreId = album.GenreId, ArtistName = (album.Artist == null) ? null : album.Artist.Name, GenreName = (album.Genre == null) ? null : album.Genre.Name }; } private static object CreateAlbumSummary(object source) { var album = source as Album; return new AlbumSummary { AlbumId = album.AlbumId, Title = album.Title, ArtistName = (album.Artist == null) ? null : album.Artist.Name }; } }
Example 1: Using LINQ
Using the mapper in a LINQ expression – convert an Album collection to an AlbumSummary collection:
IObjectMapper mapper = new ObjectMapper(); IEnumerable<AlbumSummary> summaries = repository.All<Album>() .Select(mapper.Map<Album, AlbumSummary>);
Example 1: Mapping a single object
Using the mapper for a single object:
var album = new Album { AlbumId = 1, Price = 10.0m, Title = "The Dreamer", Artist = new Artist { ArtistId = 1, Name = "José James" }, Genre = new Genre { GenreId = 1, Name = "Jazz" } }; IObjectMapper mapper = new ObjectMapper(); AlbumDetail albumDetail = mapper.Map<Album, AlbumDetail>(album);
Unit Testing
Some NUnit tests:
[Test] public void Given_a_non_existing_mapping_when_mapping_object_then_should_throw_InvalidOperationException() { // arrange IObjectMapper mapper = new ObjectMapper(); var albumDetail = new AlbumDetail(); // act/assert Assert.Throws<InvalidOperationException>(() => // non-existing mapping mapper.Map<AlbumDetail, AlbumSummary>(albumDetail) ); } [Test] public void Given_an_album_when_mapping_to_album_summary_should_equals_expected_album_summary() { // arrange IObjectMapper mapper = new ObjectMapper(); var album = new Album { AlbumId = 4, Price = 10.0m, Title = "Heritage", Artist = new Artist { ArtistId = 4, Name = "Opeth" }, Genre = new Genre { GenreId = 4, Name = "Metal" } }; var expectedAlbumSummary = new AlbumSummary { AlbumId = 4, ArtistName = "Opeth", Title = "Heritage" }; // act AlbumSummary albumSummary = mapper.Map<Album, AlbumSummary>(album); // assert Assert.AreEqual(albumSummary, expectedAlbumSummary); }
Final thoughts
In this article you learned how to reuse the code used in the Select method, and how you can use that code to map single objects. But writing mapping code is tedious and time consuming. There are mapping tools out there that can make your life easier – AutoMapper is one of them. I’ve used it in the past and I definitely recommend it. So, why use Automapper? Quoting their website:
“What makes AutoMapper interesting is that it provides some interesting conventions to take the dirty work out of figuring out how to map type A to type B. As long as type B follows AutoMapper’s established convention, almost zero configuration is needed to map two types”
“Mapping code is boring. Testing mapping code is even more boring. AutoMapper provides simple configuration of types, as well as simple testing of mappings”
References
Downloads
Download the demo project (VS2010): LINQ-Select.zip
I am not able to download the code.
Hi Dave,
Sorry about that – I forgot to give permissions to the file.
You should be able to download it now, let me know if you have any problem.
Regards,
Rui
One thing that you need to be careful of is that you are not loading all data into memory before doing your projection which is obviously very inefficient. Using the standard Automapper Map method will do this. See http://www.devtrends.co.uk/blog/stop-using-automapper-in-your-data-access-code
I agree, if you’re getting data from a database then you should filter the data first and only then you should convert it. Don’t give too much importance to the examples I provided – the main point of the article is to show how you can refactor the mapping code so you can reuse it in different places of your application(s). Maybe I shouldn’t be using the word “repository” in the example. If you download the source code you’ll see that I don’t even have a repository accessing a database, I use a collection.
But thanks anyway for your feedback.
PS: I took a look into that article before writing this post – good stuff 🙂
Thanks,
Rui
If you control the classes involved; why not use implicit operator to handle the conversion.
public partial class Album {
public static implicit operator AlbumSummary(Album album) {
return new AlbumSummary {
AlbumId = album.AlbumId,
Title = album.Title,
ArtistName = (album.Artist == null) ? null : album.Artist.Name
};
}
public static implicit operator AlbumDetail(Album album) {
return new AlbumDetail {
AlbumId = album.AlbumId,
Price = album.Price,
Title = album.Title,
ArtistId = album.ArtistId,
GenreId = album.GenreId,
ArtistName = (album.Artist == null) ? null : album.Artist.Name,
GenreName = (album.Genre == null) ? null : album.Genre.Name
};
}
}
Then you could just do
IEnumerable summaries = repository.All();
or
AlbumDetail albumDetail = album;
Hi James,
There are different ways to solve this problem.
I’d rather keep the domain entities (Album) in one assembly and the data contracts (AlbumDetail, AlbumSummary) in another, without one having knowledge of the other.
The mapping code would be in another assembly (e.g. services).
Regards,
Rui
Hi Rui,
Aye, fair enough. That’d be another (of many) reason’s to do that. It’s a good point, the implicit operator would be reliant upon having a direct coupling and dependency on the other types that it implements, whereas your method could push any coupling out to the outer layers of the system where it’s going to be more appropriate.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1241