What's the real difference between EntityState.Deleted and Remove() method? When to use each of them?

user_11982162 0
Viewed 800

I'm kinda confused about recognizing a disconnected scenario and a connected scenario, I've searched the internet but I couldn't find any real answer to my questions, I'm kinda confused about entities tracking system, connected and disconnected scenarios, when should I use the Attach method and also in differences between using the Entry(entity).State = EntityState.Deleted and Remove(entity) method, and while I was searching about the last one, most of the time, they were thought identical, but it didn't match with the test that I did and what I expected

I just made a simple console app to test the differences, and how it works is that I make a person completely outside of the context instantiation scope and then pass it to the AddPerson method, because I think this makes a disconnected scenario, right? because the Remove method will complain about why I haven't attached the entity first, so I think that tells us that we're in a disconnected scenario, I'm not sure tho

This is the app:

class Program
{
    static void Main(string[] args)
    {
        Person person = new Person()
        {
            PersonID = 1,
            Name = "John",
            Family = "Doe"
        };

        using (var context = new MyContext())
        {
            // Why this one requires attaching but the code below doesn't
            context.Person.Attach(person);
            context.Person.Remove(person);
            context.SaveChanges();

            // This method of deleting works fine without the entity being attached
            context.Entry(person).State = EntityState.Deleted;
            context.SaveChanges();

            var people = context.Person.ToList();

            foreach (var p in people)
            {
                Console.WriteLine($"PersonID: {p.PersonID} | Name: {p.Name} | Family: {p.Family}");
            }
        }

        Console.ReadKey();
    }
}

so for the Remove method, I have to Attach the entity first, otherwise, it will throw an exception, BUT when I use the Entry(person).state = EntityState.Deleted without attaching it, it works fine, and deletes the person, now why is that, isn't this a big difference? why is it not said anywhere, I've read some websites and some other similar questions on Stackoverflow too, but this wasn't said anywhere, and for the most part, these two were presumed to be the same, and do the same thing, yes they both delete the entity, but how can we describe what happened in this test, isn't this a difference between these two?

I have two questions but I think they're related to each other, so I'm just going to ask both of them here:

  1. When does exactly a disconnected scenario happen, and how can I recognize it, does it depend on the scope of the context instantiation, or on retrieving the entity directly from the context and then modifying it (with no need to attach it), or using an entity from outside of the context (like passing it from another scope to our context as a parameter, as I did in my test)?

  2. Why does the Remove method requires attaching but the EntityState.Deleted doesn't, but they're presumed identical? why should I even bother to attach the entity first, while setting the state to deleted works without needing to attach, so When to use each of them?

Basically, The way I assume that how all these work (with my current understanding of Entity Framework which is probably wrong) is that when you're in a disconnected scenario, you have to attach your entity first, but then setting the state to EntityState.Deleted doesn't need attaching, so then why does the Remove method exists at all, we could use the other way of deleting all the time.

EDIT: Based on the second code block in the accepted answer, I wrote this test, to figure out how it's working, you said that the otherPersonReference is equal to having a Attach(Person) but when I first attach the person and try to use EntityState.Deleted It works then too, and it'll delete it, but you said that it would fail, I'm a little confused :s

class Program
{
    static void Main(string[] args)
    {
        Person person = new Person()
        {
            PersonID = 3,
            Name = "John",
            Family = "Doe"
        };

        using (var context = new MyContext())
        {
            //var pr = context.Person.Single(p => p.PersonID == 3);
            context.Person.Attach(person);
            context.Entry(person).State = EntityState.Deleted;
            context.SaveChanges();
        }

        Console.ReadKey();
    }
}

if I uncomment the pr variable line and then comment the context.Person.Attach(person) then setting the EntityState to Deleted would fail and it'll throw an exception as expected

entity-framework c#
1 Answers

Setting context.Entry(person).State tells EF to start tracking the "person" instance if it isn't already tracking it. You would get an error if the DbContext was already tracking an instance for the same record.

For example, you can try the following:

var person = new Person { Id = 100 };  // assume an existing record with ID = 100;

using (var context = new AppDbContext())
{
    context.Entry(person).State = EntityState.Deleted;
    context.SaveChanges();
}

This works as you expect... However, if you were to have code that did this:

var person = new Person { Id = 100 };  // assume an existing record with ID = 100;

using (var context = new AppDbContext())
{
    var otherPersonReference = context.Persons.Single(x => x.Id == 100);
    context.Entry(person).State = EntityState.Deleted;
    context.SaveChanges();
}

Your attempt to use context.Entry(person).State = EntityState.Deleted; would fail because the context is now already tracking an entity with that ID. It's the same behaviour as if you were to try and call Attach(person).

When dealing with short-lived DbContexts (such as when using using() blocks) and single entity operations, it can be reasonably safe to work with detached entity references, but this will get a lot more "iffy" once you start dealing with multiple possible entity references (I.e. working with lists or objects sharing references etc.) and/or calls across a DbContext which may already be tracking entity references from previous operations / iterations.

Edit: Working with detached references can be problematic and you need to take extra care when doing so. My general recommendation is to avoid it wherever possible. The approach I recommend when dealing with entities is that you should never pass an entity outside of the scope of the DbContext that read it. This means leveraging a ViewModel or DTO to represent entity-sourced details outside the scope of the DbContext. A detached EF Entity can certainly work, but with a DTO it is explicitly clear that the data cannot be confused with a tracked entity. When it comes to performing operations like a Delete, you only really need to pass the ID.

For example, leveraging Automapper to help translate between DTOs and entities:

PersonDTO AddPerson(PersonDTO details)
{
    if(details == null)
        throw new ArgumentNullException("details");

    using (var context = new AppDbContext())
    {
        // TODO: Add validations such as verifying unique name/dob etc.

        var person = Mapper.Map<Person>(details); // Creates a new Person.
        context.Persons.Add(person);
        context.SaveChanges(); 
        details.PersonId = person.PersonId; // After SaveChanges we can retrieve the new row's ID.
        return details;
    }
}

PersonDTO UpdatePerson(PersonDTO details)
{
    if(details == null)
        throw new ArgumentNullException("details");

    using (var context = new AppDbContext())
    {
        var existingPerson = context.Persons.Single(x => x.PersonId == details.PersonId); // Throws if we pass an invalid PersonId.
        Mapper.Map(details, existingPerson); // copies values from our DTO into Person. Mapping is configured to only copy across allowed values.
        context.SaveChanges(); 
        return Mapper.Map<PersonDTO>(existingPerson); // Return a fresh, up to date DTO of our data record.
    }
}

void DeletePerson(int personId)
{
    using (var context = new AppDbContext())
    {
        var existingPerson = context.Persons.SingleOrDefault(x => x.PersonId == details.PersonId);
        if (existingPerson == null)
            return; // Nothing to do.

        // TODO: Verify whether the current user should be able to delete this person or not. (I.e. based on the state of the person, is it in use, etc.)
        context.Persons.Remove(existingPerson);
        context.SaveChanges(); 
    }
}

In this example a Person entity does not ever leave the scope of a DbContext. The trouble with detached entities is that whenever passing an entity around to other methods and such, those methods might assume they are working with attached, complete or complete-able (i.e. through lazy loading) entities. Was the entity loaded from a DbContext that is still "alive" so if if the code wants to check person.Address that data is either eager loaded and available, or lazy-loadable? vs. #null which could mean the person does not have an address, or that without a DbContext or lazy loading we cannot determine whether it does or not. As a general rule if a method is written to accept an entity, it should always expect to have a complete, or complete-able version of that entity. Not a detached "maybe complete, maybe not" instance, not a "new"ed up instance of a class that has some arbitrary values populated, (rather than an entity representing a data row) and not a deserialized block of JSON coming from a web client. All of those can be typed as a "Person" entity, but not a Person entity.

Edit 2: "Complete" vs. "Complete-able" A Complete entity is an entity that has all related entities eager loaded. Any method that accepts a Person should be able to access any property, including navigation properties, and receive the true value. If the Person has an Address, then a #null address should only ever mean that person does not have an address (if that is valid), not "that person does not have an address, or it just wasn't loaded." This also goes for cases where you might have a method that accepts an entity, which you haven't loaded, but want to substitute with a entity class populated with an ID and whatever data you might have on hand. That incomplete "entity" could find itself sent to other methods that expect a more complete entity. Methods should never need to guess at what they receive.

A Complete-able entity is an entity where any related entities within that entity can be lazy loaded if accessed. The consuming method doesn't need to determine whether properties are available or not, it can access Person.Address and it will always get an Address if that person is supposed to have one, whether the caller remembered to eager load it or not.

Where methods are using tightly scoped DbContexts (using()) if you return an entity then there is no way that you can guarantee later down the call-chain that this entity is complete-able. Today you can make the assurance that all properties are eager-loaded, but tomorrow a new relationship could be added leaving a navigation property somewhere within the object graph that might not be remembered to be eager-loaded.

Eager loading is also expensive, given to ensure an entity is "complete", everything needs to be loaded, whether the consumers ever need it or not. Lazy Loading was introduced to facilitate this, however, in many cases this is extremely expensive leading to a LOT of chatter with the database and the introduction of performance costs when the model evolves. Elements like serialization (a common problem in web applications) touch every property by default leading to numerous lazy load calls for every entity sent.

DTOs/ViewModels are highly recommended when data needs to leave the scope of a DbContext as it ensures only the data a consumer needs is loaded, but equally importantly, as a model may evolve, you avoid lazy loading pitfalls. Serializing a DTO rather than an Entity will ensure those new relationships don't come into play until a DTO is updated to actually need that data.

user_4234970
Related