实体框架代码第一循环依赖 [英] Entity Framework Code First Circular dependencies

问题描述

我对EF的循环依赖有点困惑，因为看起来一切都将变成循环依赖。

看看，如果可能的话，应避免使用它们。

Julie Lerman在最近的帖子中谈到了这个问题此处

在简单示例中如果您删除了Post上的Blog和BlogId属性，则您提供的实体框架应该没有任何抱怨，但是可能还有其他更复杂的情况。

实体默认情况下会添加一个数据库中帖子行中的外键到拥有博客行的外键，但域模型将仅为n

以下代码段将首先从数据库中加载第一个Blog，然后懒加载该博客的Posts。

 使用（var db = new BlogContext（））
 {
 var blog = db.Blogs.FirstOrDefault（）; 
 
 //延迟加载在前一行中获取的博客帖子
 foreach（博客文章中的var帖子）
 {
 Trace.TraceInformation（string .Format（帖子{0}的标题为{1}，post.Id，post.Title））； 
} 
} 
} 
  

如果您确实需要导航无论是从Blog到Posts，还是从Posts到Blogs，由于应用程序中的某些业务需求，您都必须在查询和双向关联之间做出决定。
实体框架完全支持您选择哪一个完全取决于您。

双向关联是指您的两边都具有导航属性，使您可以双向导航。即如果Blog具有Posts属性，并且每个Post具有指向Blog的Blog属性，则我们具有双向关联。

另一种选择是使用导航属性仅在一侧。例如。博客可能包含帖子列表，这将使从博客到帖子的导航变得容易，这可能是最需要的。
如果在某些用例中引用了某个帖子，并且需要找出该帖子属于哪个Blog，则可以通过在存储库/ dbcontext上执行查询以查找具有以下内容的Blog对象来找到该Blog：

DDD的拥护者经常建议单向导航和查询是否需要反向导航。

I am a bit confused with Circular dependencies with EF as its seems like everything will just become a circular dependency.

Looking at this tutorial

public class Blog
{
    public int BlogId { get; set; }
    public string Name { get; set; }

    public virtual List<Post> Posts { get; set; }
}

public class Post
{
    public int PostId { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }

    public int BlogId { get; set; }
    public virtual Blog Blog { get; set; }
}

When I run the "code map" in Vs2012 I do indeed see that it is a circular reference

Should I not be worried about this? I was trying to use Autofixture to generate dummy data but it crashes because of circular references.

解决方案

I guess it depends on who you ask if you should worry or not about bidirectional associations or not. In domain driven design people usually say you should worry about this. E.g. Eric Evans say in his book Domain driven design: tackling the complexity in the heart of software you should avoid them if possible.

Julie Lerman writes about the issue in a recent post here

In the simple example you provided entity framework should not have any complains if you removed the Blog and BlogId properties on Post, but there may be other more complex cases.

Entity will by default add a Foreign key in the Posts rows in the database to the owning Blogs row, but the domain model will only be navigable from Blogs to Posts.

The following snippet will first load the first Blog from the database, and then lazy load the Posts of that blog.

using (var db = new BlogContext())
{
    var blog = db.Blogs.FirstOrDefault();

    //lazy loading the Posts of the blog that was fetched in previous line        
    foreach (var post in blog.Posts)
    {
        Trace.TraceInformation(string.Format("Title of post {0} is {1}",  post.Id, post.Title));
        }
    }
}

If you really need to navigate both from Blog to Posts and from Posts to Blogs, because of some business requirement in your application, then you will have to decide between querying and a bi-directional association. Which one to choose is completely up to you, Entity Framework supports both.

A bi-directional association is when you have a navigational property on both sides, enabling you to navigate in both directions. I.e. if Blog has a Posts property and each Post has a Blog property pointing back to the Blog, then we have a bi-directional association.

An alternative option is to have a navigational property on only one side. E.g. a Blog may contain a list of Posts, this would make it easy to navigate from Blog to Posts which is probably what is most of needed. If you in some use case have a reference to a Post and need to find out which Blog it belongs to, then you could find the blog by doing a query on your repository/dbcontext searching for a Blog object that has the post in its lists of Posts.

Advocates of DDD often recommends uni-directional navigation and queries if navigation in the opposite direction is needed.

这篇关于实体框架代码第一循环依赖的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！