ASP.Net MVC与EF类库多项目下AutoMapper的正确配置咨询

这个问题我太熟了——你踩的坑就是误用了AutoMapper的静态Mapper类，它在整个应用域里只能初始化一次，你在MVC和类库两边都调用初始化，不报错才怪！而且在每个服务构造函数里重复调用，更是雪上加霜。

下面给你一套干净的解决方案，核心思路是放弃静态Mapper，改用实例化的IMapper，通过依赖注入来管理，让两个项目的映射配置既独立又能共存：

1. 先搞懂核心原则：用IMapper替代静态Mapper #

从AutoMapper 8.0之后，官方就不推荐用静态Mapper类了，它就是为全局单例设计的，根本不适合多独立配置的场景。换成实例化的IMapper，每个配置对应一个实例（或者统一管理一个包含所有配置的实例），完美解决冲突问题。

2. EF类库项目的配置：管好实体→DTO的映射 #

类库只负责自己的实体到DTO的转换，把配置封装成独立的Profile：

第一步：创建类库专属的Profile #

// 你的EF类库项目里
public class LibraryMapperProfile : Profile
{
    public LibraryMapperProfile()
    {
        // 这里只放类库需要的映射：实体→DTO
        CreateMap<Foo, FooDTO>();
        // 其他类库映射都放这，比如Bar→BarDTO之类的
    }
}

第二步：给类库做个配置入口（方便宿主项目调用） #

写个简单的扩展方法，让MVC项目能轻松注册类库的映射：

// 类库项目里
public static class LibraryMapperSetup
{
    // 方法1：直接创建IMapper实例（适合手动DI）
    public static IMapper CreateLibraryMapper()
    {
        var config = new MapperConfiguration(cfg =>
        {
            cfg.AddProfile<LibraryMapperProfile>();
        });
        // 可选：验证映射配置是否正确，提前发现错误
        config.AssertConfigurationIsValid();
        return config.CreateMapper();
    }

    // 方法2：DI容器扩展（适合用Autofac、Unity或ASP.NET Core内置DI）
    public static IServiceCollection AddLibraryAutoMapper(this IServiceCollection services)
    {
        services.AddAutoMapper(typeof(LibraryMapperProfile));
        return services;
    }
}

第三步：改造你的服务类，用依赖注入拿IMapper #

再也不要在构造函数里初始化Mapper了！改成构造函数注入：

// 类库的FooService
public class FooService
{
    private readonly IMapper _mapper;
    private readonly YourDbContext _dbContext;

    // 让DI容器把IMapper传进来，你只管拿来用
    public FooService(IMapper mapper, YourDbContext dbContext)
    {
        _mapper = mapper;
        _dbContext = dbContext;
    }

    public FooDTO GetFooById(int id)
    {
        var fooEntity = _dbContext.Foos.Find(id);
        return _mapper.Map<FooDTO>(fooEntity);
    }
}

3. ASP.NET MVC项目的配置：管好DTO→ViewModel的映射 #

MVC项目负责自己的DTO到ViewModel的转换，同时整合类库的配置：

第一步：创建MVC专属的Profile #

// MVC项目里
public class MvcMapperProfile : Profile
{
    public MvcMapperProfile()
    {
        // 这里只放MVC需要的映射：DTO→ViewModel
        CreateMap<FooDTO, FooViewModel>();
        // 其他MVC映射都放这
    }
}

第二步：在Application_Start里统一注册所有配置 #

如果你用的是传统.NET Framework的MVC（Global.asax.cs），以Unity为例：

protected void Application_Start()
{
    // 1. 配置AutoMapper，把类库和MVC的Profile都加进去
    var mapperConfig = new MapperConfiguration(cfg =>
    {
        cfg.AddProfile<LibraryMapperProfile>(); // 类库的配置
        cfg.AddProfile<MvcMapperProfile>();     // MVC自己的配置
    });
    mapperConfig.AssertConfigurationIsValid();

    // 2. 把IMapper实例注册到DI容器
    var container = new UnityContainer();
    container.RegisterInstance<IMapper>(mapperConfig.CreateMapper());
    // 顺便把类库的服务也注册了
    container.RegisterType<FooService>();
    // 告诉MVC用这个DI容器
    DependencyResolver.SetResolver(new UnityDependencyResolver(container));

    // 其他MVC初始化代码...
}

如果是ASP.NET Core MVC，就在Startup.cs里：

public void ConfigureServices(IServiceCollection services)
{
    // 一句话搞定：自动扫描当前程序集和类库的Profile
    services.AddAutoMapper(typeof(Startup), typeof(LibraryMapperProfile));
    // 注册类库的服务
    services.AddScoped<FooService>();
    // 其他服务配置...
}

4. 最后再强调几个关键点 #

• 绝对不要再调用Mapper.Initialize()：静态Mapper是全局单例，初始化一次就够了，多调用必报错。
• 配置分离：类库管实体→DTO，MVC管DTO→ViewModel，各自的Profile放在各自项目里，职责清晰，维护方便。
• 依赖注入到底：所有需要用IMapper的地方，都通过构造函数注入，不要自己new或者静态调用，这是解耦的关键。

这样配置完，你就再也不会遇到初始化冲突的问题，而且两个项目的映射配置完全独立，想改哪个改哪个，完美符合你的需求！

内容的提问来源于stack exchange，提问作者Ashley Kilgour