Question

/// <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();
}

一位朋友告诉我，AutoMapper依靠DAO实现从DTO到域的映射是不好的做法。

我不明白为什么这是不好的做法，我也不明白如何使用空引用有效地处理我的域对象。

有人可以解释一下吗？感谢

Answer 1

这主要是基于我的经验和阅读的观点。其他人可能不同意。如果您坚持将严格域实体与其他层分开，那么使用AutoMapper 填充您的域实体（DE）将被视为错误。严格的DE设计通常不会以可设置的形式公开其属性。您的实体将谨慎地控制数据的设置方式，并通过仔细验证，在允许输入成为实体的一部分之前对输入进行审核。通常，这只是采用公开提供方法的形式。我觉得这是关键系统和非常复杂的业务逻辑的有用模式。

我对上述模型的问题在于，在许多情况下，它太过分，会导致域数据的副本太多。您真的想要将从数据源加载的DTO映射到您的DE，然后将您的DE中的另一个DTO映射到您的视图吗？痛苦，有更多的虫子空间。

对于更小，更简单的系统，我认为使用良好的ORM解决方案将DE映射到数据存储更有意义，使用Onion Architecture来管理依赖关系，并将DE映射到适当的视图模型。这是AutoMapper非常有用的地方。

AutoMapper最佳实践 - 我是否应该向DAO询问有关实现从DTO到域对象的映射的信息？

1 个答案: