EF：将导航属性包含在DbSet中添加实体的结果中

Question

I am adding an entity to my DataContext. After this, I have to send this entity back on view (show result to end user).

DbSet has Add method that returns back new entity. But I need my entity with included navigation properties.

In the current moment, I make one more call to DataContext and passing newEntity's Id to find the entity.

public async Task<Entity> AddAsync(Entity entity)
{
    var savedEntity = m_DataContext.Entities.Add(entity);
    await m_DataContext.SaveChangesAsync();
    return await m_DataContext.Entities
        .Include(p=>p.SubEntity)
        .FirstAsync(p=>p.Id==savedEntity.Id);
}

Is it possible to include navigation property during adding operation?

My code works but I am looking for way to do it more gracefully.

Answer 1

When your AddAsync is called there are two possibilities for parameter entity:

• entity.SubEntity == null
• entity.SubEntity != null

If entity.SubEntity equals null, then the result of an include still ought to return a null SubEntity.

If entity.SubEntity is not null, then after adding savedEntity.SubEntity is also not null, and after saveChanges, savedEntity.SubEntity even contains the correct Ids.

So if you just return savedEntity, the returned value will include the complete subEntity.

When explaining Entity-Framework code-first you quite often find the example of Blogs and Posts, with a one-to-many relation: one blog has many posts, and one post belongs to exactly one blog.

The code is similar to the following:

public class Blog
{
    public int Id {get; set;}
    public string Name {get; set;}
    public ICollection<Post> Posts {get; set;}
}
public class Post
{
    public int Id {get; set;}
    public int BlogId {get; set;} // will become foreign key to Blog
    public virtual Blog Blog {get; set;}
    public string Text {get; set;
}
public class BlogContext : DbContext
{
    public BlogContext() : base("DbTestBlogs") {}
    public DbSet<Blog> Blogs {get; set;}
    public DbSet<Post> Posts {get; set;}
}

The following program adds a Blog with some Posts. ( subentities ). After adding the posts are included:

class Program
{
    static void Main(string[] args)
    {
        Blog blogToAdd = new Blog()
        {
            Name = "My Blog",
            Posts = new Post[]
            {
                new Post()  {Text = "My 1st Post"},
                new Post()  {Text = "My 2nd Post"},
                new Post()  {Text = "My 3rd Post"},
            },
        };
        // note: Post.BlogId and Post.Blog are not filled!

        Blog addedBlog = AddBlog(blogToAdd);
        Debug.Assert(addedBlog.Posts != null);
        Debug.Assert(addedBlog.Posts.Count() == blogToAdd.Posts.Count());
    }

    private static Blog AddBlog(Blog blogToAdd)
    {
        using (var dbContext = new BlogContext())
        {
            Blog addedBlog = dbContext.Blogs.Add(blogToAdd);
            dbContext.SaveChanges();
            return addedBlog;
        }
    }

If you run this program you'll even find that upon return the Post.BlogId and Post.Blog are filled. So during adding you don't need any include statement at all

Answer 2

NB

I realise this isn't an actual solution to the code. However it is a general solution to the OP's question.

Alternative Design Idea

If the user has entered the information for this entity, and it is just getting persisted back to the database then you don't need to send the object back to the user.

What would be better is if the UI was notified of successful persistence and then requested the new data from the navigation property via another request.

The "successful persistence" could just be the new ID of the newly added entity. This would make your AddAsync do return entity.Id . In my opinion you're violating SRP with the current implementation of the AddAsync method. My example:

public async Task<Entity> AddAsync(Entity entity)
{
    var savedEntity = m_DataContext.Entities.Add(entity);

    await m_DataContext.SaveChangesAsync();

    return entity.Id;
}

Premature Optimisations

@CallumLinington I thought about this way. And it looks organically according to single responsibility pattern. But I have the list of entities with possibility to view them (master-detail pattern). Moreover, in first I just added a created on the view entity to this list (when received the successful call back that entity was added). But it didn't look safely for me. From another hand, I want to limit calls to the database. It is the reason for implementation in this way

Unless there is a genuine reason that it isn't safe and not just your opinion and again if there is a genuine reason you want to limit calls to the database and not just your opinion, I wouldn't limit your design .

Putting unnecessary limitations on yourself before you have even fully justified the reasons will just make for bad code later on, and you will end up having to "hack" things in because your design is flawed.

Premature optimisation is a bad practise - well considered and justified optimisations are a good practise.

So for example, using a static method instead of a instance method just because you think it will save execution speed is bad.

Write the simplest way first then see where the optimisations are actually needed. - this is nearly the TDD way.