每个Controller重写ContractResolver返回EF动态代理模型时遇序列化错误

嘿，这个问题我之前踩过坑！EF的动态代理序列化确实容易出这种幺蛾子，尤其是你还在Controller里自定义了ContractResolver的情况，咱们来一步步搞定它：

方案一：直接禁用EF动态代理生成 #

如果你的业务场景不需要懒加载或者实体变更追踪功能，这是最省心的办法。只需要在你的DbContext构造函数里关掉代理生成和懒加载：

public class YourDbContext : DbContext
{
    public YourDbContext()
    {
        // 禁用动态代理生成
        this.Configuration.ProxyCreationEnabled = false;
        // 顺便关掉懒加载，避免序列化时触发额外查询
        this.Configuration.LazyLoadingEnabled = false;
    }

    // 你的DbSet定义...
}

这样EF就不会生成那些带一串乱码后缀的DynamicProxies类了，直接返回你定义的原始实体类，序列化自然就不会报“类型未被预期”的错误。

方案二：在自定义ContractResolver中映射代理类型到原始实体 #

如果你还需要动态代理的功能（比如懒加载），可以在你重写的ContractResolver里加个判断，把动态代理类型转换成对应的原始实体类型：

public class CustomContractResolver : DefaultContractResolver
{
    protected override Type ResolveContractType(Type type)
    {
        // 检查当前类型是否是EF动态代理类
        if (type.BaseType != null && type.Namespace == "System.Data.Entity.DynamicProxies")
        {
            // 返回代理类的基类（也就是你定义的原始实体类）
            return type.BaseType;
        }
        return base.ResolveContractType(type);
    }
}

这样序列化的时候，就会按照你定义的Category类来处理，而不是那个动态生成的代理类，完美避开类型识别问题。

方案三：实现DataContractResolver处理动态代理 #

如果上面两种方法都不适合你的场景，那就按照错误提示的思路，写一个DataContractResolver来专门处理动态代理类型的识别和映射：

public class ProxyDataContractResolver : DataContractResolver
{
    private readonly XmlDictionary _dictionary = new XmlDictionary();

    public override Type ResolveName(string typeName, string typeNamespace, DataContractResolver knownTypeResolver)
    {
        // 识别EF动态代理的命名空间
        if (typeNamespace == "http://schemas.datacontract.org/2004/07/System.Data.Entity.DynamicProxies")
        {
            // 从代理类型名中提取原始实体类名（去掉下划线后的乱码部分）
            var originalTypeName = typeName.Split('_')[0];
            // 替换成你的实体所在的命名空间和程序集名称
            var originalType = Type.GetType($"YourProject.Models.{originalTypeName}, YourProject");
            return originalType;
        }
        return knownTypeResolver.ResolveName(typeName, typeNamespace, null);
    }

    public override void ResolveType(Type type, DataContractResolver knownTypeResolver, out XmlDictionaryString typeName, out XmlDictionaryString typeNamespace)
    {
        knownTypeResolver.ResolveType(type, null, out typeName, out typeNamespace);
        // 如果是动态代理类型，替换成原始实体的命名空间和类名
        if (type.Namespace == "System.Data.Entity.DynamicProxies")
        {
            typeName = _dictionary.Add(type.BaseType.Name);
            typeNamespace = _dictionary.Add(type.BaseType.Namespace);
        }
    }
}

然后在你的Web API配置里启用这个Resolver（比如在Startup.cs或者Global.asax中）：

var config = GlobalConfiguration.Configuration;
var jsonFormatter = config.Formatters.JsonFormatter;
jsonFormatter.SerializerSettings.ContractResolver = new ProxyDataContractResolver();

额外推荐：使用DTO替代实体类返回 #

其实更规范的做法是定义数据传输对象（DTO），把EF实体的属性映射到DTO后再返回给前端。这样不仅能彻底解决序列化问题，还能灵活控制返回的数据结构，避免暴露不必要的属性或者出现循环引用的问题：

// 定义DTO类
public class CategoryDto
{
    public int Id { get; set; }
    public string Name { get; set; }
    // 只保留需要返回给前端的属性
}

// 在Controller中转换并返回
public IHttpActionResult GetCategory(int id)
{
    var category = db.Categories.FirstOrDefault(c => c.Id == id);
    if (category == null)
    {
        return NotFound();
    }
    // 实体转DTO
    var dto = new CategoryDto { Id = category.Id, Name = category.Name };
    return Ok(dto);
}

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