EF6 插入重复项以连接表

Question

I have following issue - I'm using generic repository to detach and reattach entity on update operation to prevent accessing it from two different objects.

This is how Update operation looks like:

        public void Update(TEntity entityToUpdate)
        {
            if (this.context.Entry(entityToUpdate).State != EntityState.Detached)
            {
            this.context.Entry(entityToUpdate).State = EntityState.Detached;
            }

            this.context.Entry(entityToUpdate).State = EntityState.Modified;
        }

When using two entities lets say like user and course

    public class User
    {
        public Guid UserId { get; set; }

        public string Email { get; set; }

        public ICollection<Course> Courses{ get; set; }
    }
}

and Course

public class Course
{
    public string Name { get; set; }

    public Guid CourseId { get; set; }

    public virtual ICollection<User> Users { get; set; }
}

public class CourseDto
{
    public string Name { get; set; }

    public Guid CourseId { get; set; }

    public virtual ICollection<Guid> Users { get; set; }
}

and I try to update course's users with following code:

  public async Task<Course> Update(Guid existingCourseId, CourseDto courseModel)
    {

        var course = await course.Repository.Query(true)
            .Include(c=> c.Users)
            .Where(e => e.CourseId == existingCourseId )
            .FirstOrDefaultAsync();

        if (course == null)
        {
            return null;
        }

        course.Users = await FindUsersByIds(courseModel.Users);

        course.Name = courseModel.Name;

        courseRepository.Update(course);

        await this.unitOfWork.SaveChangesAsync();

        return course;
    }

it doesn't work when I want to for example update only Name property. If Users property doesn't change and there is at least one user it will try to insert record to the CourseUser join table violating primary key constraint instead of 'noticing' that it is already existing in database.

Edit:

Additionally when I use Entry(entityToUpdate).State = EntityState.Unchanged before changing it to modified and move repository.Update() call before overwriting entity properties it works all fine. If somebody could explain this behaviour to me I would be really grateful

Answer 1

In a nutshell, simply don't do this with detaching and setting state to modified. You're already doing the right thing by transporting details to update via a DTO. Let EF's change tracking do it's thing and just call SaveChanges() .

I'm not sure what you're concern is warranting the Detach to "prevent accessing". All this does it tell the DbContext to treat the item as untracked, but then by setting the state to Modified, you're immediately tracking it again. The Main reasons you don't want to do this is that by setting the entity state to "Modified" you are telling EF to generate an UPDATE statement for the entire record regardless of whether any value was actually modified rather than optimizing an UPDATE statement to be run for values it detected had changed, and only if they had changed.

The issue you are likely seeing is because of this line:

course.Users = await FindUsersByIds(courseModel.Users);

I would bet money that your FindUsersByIds method is returning a non-tracked set of User entities either by AsNoTracking() or detaching those user entities before returning them. You have already eager loaded users for the given course you loaded. You might think this tells EF to remove existing references and replace them with the desired ones, but it doesn't. It just "adds" a set of Users that EF will treat as new associations where-by some of those associations already still exist in the database.

As a general rule when working with entities. Never, under any circumstances reset/overwrite a collection of related entities. Not to clear it and not to change the values associated with an entity.

If the model contains a revised list of IDs, then the proper way to update the set is to identify any users that need to be added, and any that need to be removed. Load references for the ones that need to be added to associate, and remove any from the eager loaded relationships. Also, where you expect 0 or 1 result, use SingleOrDefault rather than FirstOrdefault . First methods should only be used with an OrderBy clause where you could expect more than one entry and want a reliable, repeatable First. The exception to this would be when working with Linq against in-memory ordered sets where you can guarantee one unique find where First() will perform faster while Single() would scan the entire set. With EF generating queries First() generates a TOP(1) SQL statement where Single() generates a TOP(2) SQL statement so that performance assumption gets shot down to a bare minimum difference to enforce that expectation.

var course = await course.Repository.Query(true)
    .Include(c=> c.Users)
    .Where(e => e.CourseId == existingCourseId)
    .SingleOrDefaultAsync();

if (course == null)
    return null;

var existingUserIds = course.Users.Select(u => u.UserId);
var userIdsToAdd = courseModel.Users.Except(existingUserIds).ToList();
var userIdsToRemove = existingUserIds.Except(courseModel.Users).ToList();

if (userIdsToRemove.Any())
{
    var usersToRemove = course.Users
        .Where(u => userIdsToRemove.Contains(u.UserId))
        .ToList();
    foreach(var user in usersToRemove)
        course.Users.Remove(user);
}
if (userIdsToAdd.Any())
{
   var usersToAdd = FindUsersByIds(userIdsToAdd); // Important! Ensure this does NOT detach or use AsNoTracking()
   foreach(var user in usersToAdd)
       course.Users.Add(user);
}

course.Name = courseModel.Name;

await this.unitOfWork.SaveChangesAsync();

return course;

Basically this inspects the IDs selected to pick out the ones to add and remove, then proceeds to modify the eager loaded collection if needed. The change tracking will take care of determining what, if any SQL needs to be generated.

If the Users collection is exposed as List<User> then you can use AddRange and RemoveRange rather than the foreach loops. This won't work if they are exposed as IList<User> or IHashSet<User> or ICollection<User> .

Edit:

Based on the error mentioned, I would suggest starting by at least temporarily removing some of the variables in the equation around the particular implementation of the Repository and Unit of Work patterns and working with a scoped DbContext to begin with:

For a start try this edit:

using (var context = new AppDbContext())
{
    var course = await context.Courses
        .Include(c=> c.Users)
        .Where(e => e.CourseId == existingCourseId)
        .SingleOrDefaultAsync();

    if (course == null)
        return null;

    var existingUserIds = course.Users.Select(u => u.UserId);
    var userIdsToAdd = 

courseModel.Users.Except(existingUserIds).ToList(); var userIdsToRemove = existingUserIds.Except(courseModel.Users).ToList();

    if (userIdsToRemove.Any())
    {
        var usersToRemove = course.Users
            .Where(u => userIdsToRemove.Contains(u.UserId))
            .ToList();
        foreach(var user in usersToRemove)
            course.Users.Remove(user);
    }
    if (userIdsToAdd.Any())
    {
       var usersToAdd = FindUsersByIds(userIdsToAdd); // Important! Ensure this does NOT detach or use AsNoTracking()
       foreach(var user in usersToAdd)
           course.Users.Add(user);
    }

    course.Name = courseModel.Name;

    await context.SaveChangesAsync();
    context.Entry(course).State = EntityState.Detached; // Necesssary evil as this method is returning an entity.
    return course;
}

This is only intended as a temporary measure to help identify if your repository or unit of work could be leading to transient DbContexts being used to load and track entities. This could still have issues depending on what happens to the Course after this method returns it. In this case since we are leaving the scope of the DbContext instance that is tracking it, we detach it. The next step would be to ensure that a DbContext, either directly or accessible through the unit of work can be injected and that it is guaranteed to be scoped to the web request (if web) or a scope suited to the unit of work this operation is part of. (A bit more work for things like WPF desktop applications)

Normally for something like a web application you would want to ensure that a DbContext has a lifetime scope of the web request (or shorter) but not Transient. We want to ensure that all operations within a unit of work reference the same DbContext instance otherwise you end up working with entities that might be tracked by multiple DbContexts, or start introducing code to mix tracked and untracked (detached) entities to get around problems when passing entity references around. Working with detached entities requires a lot of extra boiler-plate, disciplined coding to ensure DbContexts are working with the correct, single reference of entities to avoid "already tracked" type errors or duplicate data insertion / PK violation exceptions. Ie pre-checking each and every DbSet.Local in a entity graph of related entities for any currently tracked instances with the same ID and replacing references when wanting to attach an entity graph to a DbContext that isn't already tracking that instance.