I’ve added a LookUp property to the InterceptionContext to make it easier to see which rows were affected during the After() interception phase.
public class InterceptionContext { public DbContextBase DbContext { get; internal set; } public ObjectContext ObjectContext { get; internal set; } public ObjectStateManager ObjectStateManager { get; internal set; } public DbChangeTracker ChangeTracker { get; internal set; } public IEnumerable<DbEntityEntry> Entries { get; internal set; } public ILookup<EntityState, DbEntityEntry> EntriesByState { get; internal set; } ... snipped for brevity
EntriesByState is populated prior to the call to Before(). Added and Modified entities will have their EntityState reverted to UnChanged after SaveChanges() is called. EntriesByState preserves the original state of the entities so that After() interceptors can make use of new Id’s and such.
Hey there Chris…
I absolutely love what you’ve done with Isg.EntityFramework and am using it in a greenfield project. It’s proving to be immeasurably valuable.
One of the things I am doing is using the interception capabilities and I’m using your SoftDelete interceptor as it came ‘out of the box’. The point is that I do have one small suggestion – I believe it would be better to put the ISoftDelete interface in a separate assembly.
I’m using an onion architecture with the core domain model at the centre with a repository wrapped around it. I don’t at all mind that the domain model has a concept of soft deletes, I’m happy to not abstract this in the repository, but it does mean that in referencing the ISoftDelete interface, the core library is ‘aware’ of the actual implementation.
It’s not a big problem, just seems better that way. I always put my interfaces in separate libraries. 🙂
Again, great work… I love it! (Saved my life!)
Cheers,
Paul.
PS: Just to grab your attention I think I’ll post this as an issue on BitBucket too. 🙂