Question

I’ve got standard Create() Edit() and Delete() methods on my controllers, and I am using the EF4 Self-tracking entities.

When the edit is posted back, the model.ChangeTracker.ChangeTracking = false, and model.ChangeTracker.State = ObjectState.Added, even though I made sure those are set when retrieving the record initially.

Are the self-tracking entities not persisting the ChangeTracker class when the form is submitted? If so, how do I fix that?

public virtual ActionResult Edit(int personId)
{
    IContext context = ContextFactory.GetContext();
    EntityRepo Repo = new EntityRepo(context);
    Person d = Repo.Person.GetById(PersonId);
    d.ChangeTracker.ChangeTrackingEnabled = true;
    return View(d);
}

[HttpPost]
public virtual ActionResult Edit(int personId, Person item)
{
    try
    {
        if (ModelState.IsValid)
        {
            IContext context = ContextFactory.GetContext();
            EntityRepo Repo = new EntityRepo(context);

            // the item is returning these properties that are wrong
            //item.ChangeTracker.ChangeTrackingEnabled = false;
            //item.ChangeTracker.State = ObjectState.Added;

            Repo.Person.Update(item);
            Repo.Person.SaveChanges();

            return RedirectToAction("Index");
        }
    }
    catch
    {
    }
    return View();
}

Answer 1

Let’s start at the beginning.

What are Self-Tracking Entities, exactly?

A Self-Tracking Entity is an entity which can do change tracking even when it is not connected to a ObjectContext. They are useful in times when you must change the entity, but cannot have it connected to an ObjectContext.

So when would I want one, really?

Mostly, when you must have distributed objects. For example, one use case is when you are making a web service which talks to a Silverlight client. However, other tools, like RIA Services may be a better fit here. Another possible use case is for a long-running task. Since an ObjectContext is intended to be a unit of work and should typically not be long-lived, having a disconnected entity might make sense here.

Do they make any sense for MVC?

Not really, no.

Let’s look at this a little deeper, and examine what happens when you update an entity in MVC. The general process is like this:

1. The browser issues a GET request for an update page.
2. The MVC app fetches an entity, and uses it to build an update HTML page. The page is served to the browser, and most C# objects, including your entity, are disposed. At this point, you can restart the Web server, and the browser will never know the difference.
3. The browser issues a POST request to update the entity.
4. The MVC framework uses the data in the POST in order to materialize an instance of an edit model which is passed to the update action. This might happen to be the same type as the entity, but it is a new instance.
5. The MVC app can update the entity and pass those changes back to the database.

Now, you could make self-tracking entities work by also including the full state of the STE in the HTML form and POSTing that back to the MVC app along with the scalar values on the entity. Then the Self-Tracking Entity might at least work.

But what benefit does this give you? The browser obviously cannot deal with your entity as a C# object. So it cannot make any changes to the entity worth tracking in terms that a Self-Tracking Entity would understand.