Question

Scenario:

1. Retrieve some entities
2. Update some properties on those entities
3. You perform some sort of business logic which dictates that you should no longer have those properties updated; instead you should insert some new entities documenting the results of your business logic.
4. Insert said new entities
5. SaveChanges();

Obviously in the above example calling SaveChanges() will not only insert the new entities, but update the properties on the original entities. Before I have managed to rearrange my code in a way where changes to the context (and its entities) would only be made when I knew for sure that I would want all my changes saved, however that’s not always possible. So the question is what is the best way to handle this scenario? I don’t work with the context directly, rather through repositories, if that matters. Is there a simple way to revert the entities to their original values? What is the best practice in this sort of scenario?

Update

Although I disagree with Ladislav that the business logic should be rearranged in such way that the validation always come before any modification to the entities, I agree that the solution should really be persisting wanted changes on a different context. The reason I disagree is because my business transaction is fairly long, and validation or error checking that might happen at the end of the transaction are not always obvious upfront. Imagine a Christmas tree you’re decorating with lights from the top down, you’ve already modified the tree by the time you’re working on the lower branches. What happens if one of the lights breaks? You want to roll back all of your changes, but you want to create some ERROR entities. As Ladislav suggested the most straight forward way would be to save the ERROR entities on a different context, allowing the original one (with the modified metaphorical tree) to expire without SaveChanges being ever called.

Now, in my situation I utilize Ninject for dependance injection, injecting one EF context into all of my repositories that are in the scope of the top level service. What this means is that my business layer classes don’t really have control of creating new EF contexts. Not only do they not have access to the EF context (remember they work through repositories), but the injection has already occurred higher in the object hierarchy. The only solution I found is to create another class that will utilize Ninject to create a new UOW within it.

//business logic executing against repositories with already injected and shared (unit of work) context
Tree = treeRepository.Get();
Lights = lightsRepsitory.Get();

//update the tree as you're decorating it with lights

if(errors.Count == 0)
{
    //no errors, calling SaveChanges() on any one repository will commit the entire UOW as they all share the same injected EF context
    repository1.SaveChanges();  
}
else
{
    //oops one of the lights broke, we need to insert some Error entities
    //however if we just add id to the errorRepository and call SaveChanges() the modifications that happened
    //to the tree will also be committed.
    TreeDecoratorErroHandler.Handle(errors);    
}

internal class TreeDecoratorErroHandler
{
    //declare repositories
    //constructor that takes repository instances

    public static void Handle(IList<Error> errors)
    {
        //create a new Ninject kernel
        using(Ninject... = new Ninject...)
        {
            //this will create an instance that will get injected with repositories sharing a new EF instance
            //completely separate from the one outside of this class
            TreeDecoratorErroHandler errorHandler = ninjectKernel.Get<TreeDecoratorErroHandler>();
            //this will insert the errors and call SaveChanges(), the only changes in this new context are the errors
            errorHandler.InsertErrors(errors);
        }       
    }

    //other methods
}

Answer 1

You should definitely use a new context for this. Context is unit of work and once your business logic says: “Hey I don’t want to update this entity” then the entity is not part of unit of work. You can either detach the entity or create new context.

There is possibility to use Refresh method but that method is supposed to be used in scenarios where you have to deal with optimistic concurrency. Because of that this method refreshes only scalar and complex properties and foreign keys if part of the entity – if you made changes to navigation properties these can be still present after you refresh the entity.