DbSet.Add & DbSet.Remove Versus using EntityState.Added & EntityState.Deleted
In entity framework 6, there are several ways to add / remove objects, for example to add entities, we can use: -
b.Students.Add(student);
db.SaveChanges();
OR
db.Entry(student).State = EntityState.Added; db.SaveChanges();
and in a similar way when deleting an object: -
db.Entry(studentToDelete).State = EntityState.Deleted; db.SaveChanges();
OR
db.Remove(StudentToDelete)
db.SaveChanges();
I haven't found many resources that talk about the differences, and most online guides mention both approaches as if they were the same. but I read the answer to the article link that using dbset.Add set the status for the entity and all related entities / collections, adding when using EntityState.Added
will add also all related entities / collections to the context, but leaves them as unmodified, and the same refers to dbset.Remove
andEntityState.Deleted
so are these differences true?
Edit
As I understand it, a graph operation means the parent and child have been removed / added if the parent is marked for removal or for adding. so i did these two tests: -
using (var db = new TestContext())
{
var a = new Department { DepartmentName = "Shipping" };
var b = new Employee { FirstName = "Bob", LastName = "Dodds", Department = a };
db.Entry(b).State = EntityState.Added;
db.SaveChanges();
}
using (var db = new TestContext())
{
var a2 = new Department { DepartmentName = "Production" };
var b2 = new Employee { FirstName = "Sarah", LastName = "Gomez", Department = a2 };
db.Employees.Add(b2);
db.SaveChanges();
}
where both added department and employee. so can you take part in this please?
source to share
From Lerman and Miller's book DbContext (p. 80):
Calling
DbSet.Add
and settingState
onAdded
both achieves exactly the same.
What is:
If an object is not tracked by the context, it will start being tracked by the context into state
Added
. BothDbSet.Add
and settingState
toAdded
are graph operations - which means that any other objects that are not tracked by the context and inaccessible from the root entity will also be marked asAdded
. If the object (root object is my additon) is already tracked in the context, it will be moved into stateAdded
.
Please note that you answered this question incorrectly. The book was written with EF 4.3 in mind, and it doesn't mention any shift changes since EF 4.1 was when it was introduced DbContext
.
Setting the state of an object to be deleted (either through DbSet.Remove()
or by setting Entry(entity).State
to Deleted
) is not a graphical operator. It only affects the state of the object, not the objects in its object graph.
The latter is true for any state of the object, except Added
.
The exception to this rule is when cascading delete is configured in both the database and the EF model. In a many-to-many connection with a hidden jump table, cascading delete is the default, so the connection records are always deleted when the root object is marked for deletion (either by setting its state to Deleted
or deleting it from it DbSet
).
For example, let's say A
they B
have a many-to-many association. The junction table AB
is only in the database, not in the class model. If you select A
from a database (without Include()
-ing its B
s) and delete it, A
all its entries are deleted as well AB
, but not B
deleted.
When cascading deletion is configured in a one-to-many association, "many" entities will be deleted when entity "1" is deleted. If A
u B
have a one-to-many association, deleting A
it will also remove it B
s.
source to share