Entity Framework Code First Circular dependencies

Question

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.

Answer 1

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.