Question

Assume that I have the following little console application which uses Entity Framework 5:

class Program {

    static void Main(string[] args) {

        using (var ctx = new ConfContext()) {

            var personBefore = ctx.People.First();
            Console.WriteLine(personBefore.Name);

            personBefore.Name = "Foo2";
            ctx.SaveChanges();

            var personAfter = ctx.People.First();
            Console.WriteLine(personAfter.Name);
        }

        Console.ReadLine();
    }
}

public class ConfContext : DbContext {

    public IDbSet<Person> People { get; set; }
    public IDbSet<Session> Sessions { get; set; }
}

public class Person {

    [Key]
    public int Key { get; set; }

    public string Name { get; set; }
    public string Surname { get; set; }
    public DateTime? BirthDate { get; set; }

    public ICollection<Session> Sessions { get; set; }
}

public class Session {

    [Key]
    public int Key { get; set; }
    public int PersonKey { get; set; }

    public string RoomName { get; set; }
    public string SessionName { get; set; }

    public Person Person { get; set; }
}

As you can see, I am changing the name of the record and saving it. It works but it feels like magic to me. What I am doing in all of my applications is the following one (to be more accurate, inside the Edit method of my generic repository):

static void Main(string[] args) {

    using (var ctx = new ConfContext()) {

        var personBefore = ctx.People.First();
        Console.WriteLine(personBefore.Name);

        personBefore.Name = "Foo2";
        var entity = ctx.Entry<Person>(personBefore);
        entity.State = EntityState.Modified;
        ctx.SaveChanges();

        var personAfter = ctx.People.First();
        Console.WriteLine(personAfter.Name);
    }

    Console.ReadLine();
}

There is no doubt that the second one is more semantic but is there any other obvious differences?

Answer 1

Well the second code block where you explicitly set the entity state is redundant, as the change tracker already knows that the entity is modified because the context knows about the entity (as you query the context to retrieve the entity).

Setting (or painting) the state of the entity would be more useful when working with disconnected entities, for example in an n-tier environment where the entity was retrieved in a different context and sent to a client for modification, and you wish to mark those changes back on the server using a different context.

Otherwise, the first code block is cleaner in my opinion.