0

I'm using EF 4.2 where the relevant bits look like:

public class MyDbContext : DbContext            
{        
   public IDbSet<User> Users { get; set; }
   public IDbSet<Membership> Memberships { get; set; }
}

public User()
{          
    public int Id { get; set; }        
    public string Email { get; set; }

    public virtual Membership Membership { get; set; }
}

If I pull back a particular User and then update the associated Membership object (to say update the failed password count) the Membership object gets updated, but so does the User despite the fact that none of the User properties have been updated. Is this because the Membership object has fired some sort of changed event and it's bubbled up to the parent User?

This occurs even if I load the User and then get the Membership using _context.Memberships.Find(userId) rather than just using the user.Membership navigation property. I'm guessing in the context graph these two are equivalent?

Is there any way to stop the User object being updated as I use a calculated value column of date modified and I would prefer this were not updated when the child entity is altered. Ideally I want to pull back the User object rather than just querying the Membership DbSet as I want to read some of the User properties too.

The SQL which is fired on the parent Users table is:

update [dbo].[Users]
set @p = 0
where (([Id] = @0) and ([Version] = @1))
Robert Roe
  • 122
  • 9
  • 1
    possible duplicate of [EF4 - update \[Table\] set @p = 0 where ](http://stackoverflow.com/questions/6232185/ef4-update-table-set-p-0-where) – Ladislav Mrnka Feb 06 '12 at 12:56
  • Given Membership is part of your User aggregate, you should be glad your User aggregate root is changed as well. Otherwise Membership is not part of the User aggregate and should be treated as a separate aggregate (i.e. not a property of User). Sidenote: don't expose your state (Membership). Try something more object oriented like aUser.IncrementNumberOfFailedAuthenticationRequests(). – Yves Reynhout Feb 27 '12 at 17:19
  • @YvesReynhout I see you point of view and I mainly agree with it, in many ways it is correct to update the User aggregate root too. There is a hotfix to "correct" the behaviour so I guess for a significant number of people it was unexpected behaviour. That doesn't mean they were right to change it ;) I'm not 100% convinced by notion of having a method to update the underlying membership as that would mean you would potentially need a method for every property of every underlying object you wanted to update and somewhat decrease the usefulness of the complex objects of EF? – Robert Roe Feb 28 '12 at 14:39
  • The methods represent system behavior/use cases, doubtful there will be an explosion of those. I have yet to see an example where this would be problematic (without it being a violation of SRP or lumping things together that don't belong together). As for the usefulness of "complex" EF objects, my reaction is: What's complex about them other than maybe the mapping magic going on? They are just data, nothing more, nothing less. – Yves Reynhout Feb 28 '12 at 16:12

0 Answers0