Entity Framework 4.1 - default EntityState for a F

问题:

I'm having a small problem with ASP.NET MVC and Entity Framework 4. I have an entity called "UF" and another one called "Pais", and they have this relation:

UF [* ... 0..1] Pais

I can access the Pais object directly from UF using a navigation property:

UF.Pais.Whatever = "foobar";

Currently I have a View which inserts a new item into the database, and it has an editor for "Pais.Codigo" ("Codigo" is the primary key for Pais). So when I insert a new UF, the framework creates an instance of class UF with a reference to an instance of class Pais. Then this is done:

if (ModelState.IsValid)
{
    db.UFs.AddObject(uf);
    db.SaveChanges();

    return View();
}

The problem is that the EF is inserting a new Pais into the database, so it basically ignores the existing one.

For example, if let's say my object UF has a Pais with an ID of 1. The current value of uf.Pais.Codigo is 1. Other attributes, like the description, is currently null. When I execute the SaveChanges, both "uf" and "uf.Pais" are with the state of Added. The correct state for "uf.Pais" should be Unchanged, since it already exists on the database.

My question is: there's some way of changing the default relationship EntityState for Unchanged? The following code solves the problem, but adding it to each function with adds a new entry to the database (and for each FK) is overkill!

db.ObjectStateManager.ChangeObjectState(uf.Pais, EntityState.Unchanged);

That's it. I'm not sure if I was clear enough. Feel free to ask more information if needed. And sorry for any english mistakes!

Thanks,

Ricardo

PS: "Pais" stands for Country and "UF" for State.

回答1:

My question is: there's some way of changing the default relationship EntityState for Unchanged?

Yes by calling Attach instead of Unchanged.

The following code solves the problem, but adding it to each function with adds a new entry to the database (and for each FK) is overkill!

No it is not overkill, it is a solution because either Attach or AddObject will always make the operation for all entities and associations in entity graph. That means that calling AddObject will make everything what context is not aware of yet as Added and Attach will make everything what context is not aware of as Unchanged (so you will in turn have to set each modified or inserted entity to its correct state). That is how EF works if you are using detached entities.

Another solution for the problem is making the connection after the UF is added:

// Here UF.Pais is null
db.UFs.AddObject(uf);
// Create dummy Pais
var pais = new Pais { Id = "Codigo" };
// Make context aware of Pais
db.Pais.Attach(pais);
// Now make the relation
uf.Pais = pais;
db.SaveChanges();

If you are working with detached entities you are always responsible for setting the correct state for each entity (and independent association). So you will either use attached entities to let EF make the magic for you (as shown in the example) or you will use the approach you dislike. In more complex scenarios you can find out that best approach is to load entity graph again and merge incoming changes into the attached graph.