CODEWITHSUNDEEP
asp.net-mvcentity-frameworkcrud
markzzz
markzzz

Reputation: 47947

What's the differences between EntityState.Added and Add()?

I'm recently using this to add entity EF to my DB:

ctx.Entry(payment).State = payments.ID == 0 ? EntityState.Added : EntityState.Modified;

Instead of the common:

ctx.Payments.Add(payments);

The second is nice because I can choose if add or delete.

What's the real difference between the first and the second approch? And why there isn't a straightforward for update item? Such as:

ctx.Payments.Update(payments);

Which will "mirror" the EntityState.Modified one?

This is the code I'm using, setting a ViewModel from my MVC Action/Controller to my EF context:

IList<Payments> newPayments = activityViewModel.Payments.Select(p => mapper.Map<PaymentViewModel, Payments>(p)).ToList();

foreach (var payments in newPayments)
{
    ctx.Entry(payments).State = payments.ID == 0 ? EntityState.Added : EntityState.Modified;
    ctx.Payments.Add(payments);
}

ctx.SaveChanges();

Upvotes: 1

Views: 1049

Answers (1)

user743382
user743382

Reputation:

There is no difference between adding a detached entity by setting its state vs. calling Add.

You can see in InternalEntityEntry.cs (wrapped by DbEntityEntry) that setting the state to Added just ends up calling InternalSet.Add. You can see in DbSet`.cs that calling Add also just ends up calling InternalSet.Add. They differ a bit in their preconditions, but in your case, the preconditions of both are met.

The nice part about the first approach, in your case, is that the same bit of code can either add an entity, or attach it and mark it as modified. As you noted, there is no single-method alternative for setting the state to Modified.

The second is nice because I can choose if add or delete.

You can also set the state to Deleted, so that is not an advantage of either over the other.

And why there isn't a straightforward for update item?

Likely because the only use case for it is when you're doing something strange, from EF perspective. Detaching, serialising, modifying, de-serialising and re-attaching entities may be the norm in your framework, but from EF perspective, those are advanced low-level operations with a somewhat enlarged risk of things going wrong. For instance, when your model contains any modifiable property also used for concurrency checks, the fact that your serialisation-deserialisation loses the property's original value means that the concurrency check is sure to fail.

Upvotes: 2

Related Questions