entity-framework-4 – 首先在实体框架代码中使用导航属性

public IQueryable<Topic> GetTopics()
{
    // return DbContext.Topics;                   // OK
    return DbContext.Topics.Include("Creator");   //With Exception
}

这不是代码优先或EF的问题 – 这是序列化的问题.用于将对象图转换为Web API消息中传递的某些表示形式的序列化程序默认情况下无法使用循环引用.根据您要使用的消息格式,Web API默认使用不同的序列化程序 – here更多地是关于Web API使用的默认序列化程序以及如何更改它的方式.下面的文本假设您正在使用DataContractJsonSerializer或DataContractSerializer(应该是XML序列化的默认值),但JSON.NET也是可以的(对于JSON序列化应该是默认的 – JSON序列化可以切换到DataContractJsonSerializer但默认的序列化程序更好) .

那么你能做什么？您可以告诉序列化程序它应该通过使用DataContract(IsReference = true)标记您的类来跟踪这些循环引用,并使用DataMember属性标记每个传递的属性(查看链接文章以获取如何使用JSON.NET实现它的描述).这将允许序列化器正确识别循环,并且序列化在理论上将成功.理论上因为这也要求不使用延迟加载.否则,您可以序列化比预期更多的数据(在某些灾难性情况下,它可能导致序列化数据库的整个内容).

当您使用延迟加载序列化实体图时,您会对主题及其创建者进行搜索,但序列化也会访问CreatedTopics property =>所有相关主题都是延迟加载和序列化处理,序列化继续访问所有新加载主题的Creator！此过程将继续,直到没有其他对象延迟加载.因此,在序列化实体时不应使用延迟加载.

其他选项是从序列化中排除反向引用.你只需要序列化Creator.您不需要序列化CreatedTopics,因此您可以使用IgnoreDataMember属性(JSONIgnore for JSON.NET)标记该属性.问题是,如果您还使用Web API操作来返回User及其所有CreateTopics,则由于该属性,这将无效.

最后一个选项不使用实体.此选项通常用于Web服务,您可以在其中创建满足特定操作要求的特殊DTO对象,并处理操作中实体和DTO之间的转换(可以借助AutoMapper等工具).

处理一对一,一对多或多对多关系之间没有区别.如果双方都有导航属性,则必须始终处理此问题.