Attaching and detaching entities from context correctly in EF4.1

IEntityWithKey is interface for other types of entities. It is for "big" entities. For example EntityObject implement this interface. These entities are not considered as POCO and are not supported by DbContext API.

If you want to use IEntityWithKey your classes must implement it - it is not something that would happen automatically.

Correct attaching with DbContext API should be:

dbContext.Set(typeof(entity)).Attach(entity); 

and this should hopefully also work:

dbContext.Entry(entity).State = EntityState.Unchanged;

Correct detaching with DbContext API should be:

dbContext.Entry(entity).State = EntityState.Detached;

Also it is better to you generic methods instead of object.

To your follow-up question:

...how do we make it keep the navigational properties and NOT replace(or lose) them with NULL when we detach from context...

I believe it's not possible to detach an object graph from the context while maintaining it's navigation properties. From MSDN:

In an independent association, the relationship information is not maintained for a detached object.

Although this statement is about independent associations it does not mean that navigation properties are maintained in foreign key assocation (relationships which expose a foreign key property in the model). Yes, "Relationship information" is maintained because the foreign key properties (which are scalar properties) will be alive and contain the correct foreign key value after detaching. But the corresponding navigation properties will still be null for reference properties or, for navigation collections the reference will be removed from the collection.

I think the only way to detach a complete object graph from a context is either disposing the context altogether or create a copy of the graph before starting to detach the original graph. Creating a copy would require writing Clone methods which copy all the properties and navigate through the graph or using a "trick" like this which serializes the graph into a binary stream and then deserializes it back to new objects. For this the entities would need to be serializable. Also reference cycles (which we often have when using bidirectional navigation properties between entities) can cause trouble. (Also attention if your objects are proxies which contain references to EF's internal objects and which you probably don't want to copy, serialize and deserialize.)

In this aspect Detach is not the counterpart of Attach because it behaves quite differently: Attach attaches the whole object graph and maintains navigation properties. Detach detaches only single entities without the related objects and destroys navigation properties. From the same page linked above:

Detach only affects the specific object passed to the method. If the object being detached has related objects in the object context, those objects are not detached.

I could imagine that this is the main reason why the DbContext API doesn't have an explicite Detach method (in contrast to ObjectContext) - detaching is considered as an advanced feature which does not behave as one might expect.

MSDN mentions as the only reason to detach an object from the context "to conserve resources" (again the article above):

In Entity Framework applications, you can detach objects from the object context. You might detach objects to conserve resources, as executing repeated queries in the same object context increases the memory requirements of the object context.

I think this method is just not prepared and designed for working with the objects after they've been detached from the context. It's main purpose is to release them for immediate garbage collection.