Removing a Detach
method from the (DbContext
) API has some logic because Detach
doesn't operate on an object graph but it only detaches the single object that you pass into the method. This is different to all other methods that change the object state:
Attach
attaches the supplied object including all related objects in the object graph of navigation properties
Add
adds the supplied object including all related objects to the context
Remove
deletes the supplied object including the related objects that have been configured with cascading delete
On the other hand setting the state manually to Modified
, Added
or Deleted
always only acts on the supplied object, not on the related objects. This is also the case for calling the Detach
method of ObjectContext
. It is more consequent to detach an object only via setting the state to Detached
to be in line with the behaviour of other state changes because like setting any other state it only influences the supplied object without related objects.
DbContext
is - among other features - intended to make working with Entity Framework easier. The old Detach
method was more confusing and its behaviour is not like many developers expect. (Here and here are two references about this confusion and the complexities involved in detaching an object.) In my opinion it wasn't the wrong step to remove it from the DbContext
API.
Well, you can always write you own extension method like you did or access the underlying ObjectContext
via the adapter if you really want to have a Detach
method.