Wykorzystanie Automappera ma swoje uzasadnienie i często-gęsto można je uznać za "kod pożądany". Pomimo swych zalet ma jednak również wady. Jedną z nich są z pewnością dość długaśne instrukcje wykonujące mapowanie:
1: var mapped = Mapper.Map<IEnumerable<MyClass>, IEnumerable<MyMappedClass>>(source);
Takie coś powtarzane ołwer-and-ołwer-egen potrafi zirytować.
A gdyby to uprościć? Do:
1: var mapped = source.Map<IEnumerable<MyMappedClass>>();
Nadal nie jest to piękne, ale już chyba niewiele dalej można upraszczanie kodu pociągnąć.
Aż mi głupio, że korzystając z Automappera przez dobre kilkanaście/dziesiąt miesięcy i od samego właściwie początku zżymając się na umawianą składnię dopiero niedawno napisałem takież otóż extension methods:
1: public static class MappingExtensions 2: { 3: public static object Map(this object @this, Type destinationType) 4: { 5: return Mapper.Map(@this, @this.GetType(), destinationType); 6: } 7: 8: public static TDestination Map<TDestination>(this object @this) 9: { 10: if (@this == null) 11: { 12: return default(TDestination); 13: } 14: 15: return (TDestination) @this.Map(typeof (TDestination)); 16: } 17: 18: public static TDestination Map<TSource, TDestination>(this TSource @this) 19: { 20: return Mapper.Map<TSource, TDestination>(@this); 21: } 22: //...
Banalność, ale… enjoy.
Tak tylko kwestią uściślenia AutoMapper nie wymaga definiowania mapowań dla IEnumerable<T>. Wystarczy mu mapowanie dla T. Automatycznie rozpoznaje mapowania dla kolekcji.
Pomijając to ciekawe rozwiązanie :). Dzięki.
Info tutaj: http://automapper.codeplex.com/wikipage?title=Lists%20and%20Arrays
@Paweł:
Tak, jasne, ale już żeby zmapować IEnumerable to trzeba do Map podać cały typ:). I w sumie o to mi tylko chodziło – rozpieszczony ‘var’ami i type inference nie lubię takich szlaczków mazać.