/// <summary>
/// Initialize the AutoMapper mappings for the solution.
/// http://automapper.codeplex.com/
/// </summary>
public static void CreateAutoMapperMaps()
{
IDaoFactory daoFactory = DependencyResolver.Current.GetService<IDaoFactory>();
Mapper.CreateMap<Error, ErrorDto>()
.ReverseMap();
IPlaylistDao playlistDao = daoFactory.GetPlaylistDao();
IUserDao userDao = daoFactory.GetUserDao();
Mapper.CreateMap<Playlist, PlaylistDto>();
Mapper.CreateMap<PlaylistDto, Playlist>()
.ForMember(playlist => playlist.User, opt => opt.MapFrom(playlistDto => userDao.Get(playlistDto.UserId)));
Mapper.CreateMap<PlaylistItem, PlaylistItemDto>();
Mapper.CreateMap<PlaylistItemDto, PlaylistItem>()
.ForMember(playlistItem => playlistItem.Playlist,
opt => opt.MapFrom(playlistItemDto => playlistDao.Get(playlistItemDto.PlaylistId)));
Mapper.CreateMap<ShareCode, ShareCodeDto>().ReverseMap();
Mapper.CreateMap<User, UserDto>().ReverseMap();
Mapper.CreateMap<Video, VideoDto>().ReverseMap();
Mapper.AssertConfigurationIsValid();
}
A friend is telling me that it is bad practice for AutoMapper to rely on DAOs to fulfill mappings from DTO to Domain.
I don't understand why this is bad practice nor do I understand how it would be possible to effectively work on my domain object with null references.
Can anyone explain? Thanks
This is mostly my opinion based on my experience and reading. Others might disagree. If you hold to a strict domain entity separation from other tiers, then using AutoMapper to populate your domain entity (DE) would be considered bad. Strict DE design generally will not expose its properties in settable form. Your entity will jealously control how the data is set with careful validation that vets the input before permitting it to become part of the entity. Often this takes the form of only making methods available publicly. I feel this is a useful mode for critical systems and very complex business logic.
My problem with the above model is that in many situations, it is overkill and will result in way too many copies of your domain data. Do you really want to map a DTO loaded from your datasource to your DE, then map another DTO from your DE to your view? Painful, with more room for bugs.
For smaller, simpler systems, I think it makes more sense to make your DE map to the data store with a good ORM solution, use an Onion Architecture to manage dependencies, and map your DE to view models as appropriate. This is where AutoMapper is very helpful.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With