Marco de la entidad: ¿por qué se establece explícitamente el estado de la entidad a modificado?

Question

La documentación oficial dice que para modificar una entidad, recupero un objeto DbEntityEntry y trabajo con las funciones de propiedad o configuro su estado para modificarlo. Utiliza el siguiente ejemplo

Department dpt = context.Departments.FirstOrDefault(); 
DbEntityEntry entry = context.Entry(dpt); 
entry.State = EntityState.Modified; 

No entiendo el propósito de la segunda y tercera afirmación. Si le pido el marco para una entidad como la primera declaración no y luego modificar la POCO como en

dpt.Name = "Blah" 

si yo pido EF para SaveChanges(), la entidad tiene un estado de MODIFICADOS (soy adivinar mediante el seguimiento de instantáneas, esto no es un proxy) y los cambios se mantienen sin la necesidad de configurar manualmente el estado. ¿Me estoy perdiendo de algo?

Answer 1

En su escenario, de hecho, no tiene que establecer el estado. El objetivo del seguimiento de cambios es encontrar que ha cambiado un valor en la entidad adjunta y ponerlo en estado modificado. La configuración manual del estado es importante en el caso de entidades separadas (entidades cargadas sin seguimiento de cambios o creadas fuera del contexto actual).

Answer 2

Como se dijo, en un escenario con entidades desconectadas, puede ser útil establecer el estado de una entidad en Modified. Guarda una ida y vuelta a la base de datos si solo adjunta la entidad desconectada, en lugar de extraer la entidad de la base de datos y modificarla y guardarla.

Pero puede haber muy buenas razones para no establecer el estado en Modified (y estoy seguro de que Ladislav era consciente de esto, pero aún me gustaría señalarlo aquí).

1. Todos los campos en el registro se actualizarán, no solo los cambios. Hay muchos sistemas en los que se auditan las actualizaciones. La actualización de todos los campos generará grandes cantidades de desorden o requerirá que el mecanismo de auditoría filtre los cambios falsos.

2. concurrencia optimista. Dado que todos los campos están actualizados, esto puede causar más conflictos de los necesarios. Si dos usuarios actualizan los mismos registros al mismo tiempo, pero no los mismos campos, no es necesario que exista un conflicto. Pero si siempre actualizan todos los campos, el último usuario siempre intentará escribir datos obsoletos. Esto, en el mejor de los casos, provocará una excepción de simultaneidad optimista o, en el peor de los casos, una pérdida de datos.

3. Actualizaciones inútiles. La entidad se marca como modificada, no importa qué. Las entidades sin cambios también lanzarán una actualización. Esto puede ocurrir fácilmente si las ventanas de edición se pueden abrir para ver detalles y se cierran por OK.

Así que es un buen equilibrio. Reduzca los viajes de ida y vuelta o reduzca la redundancia.

todos modos, la alternativa a la configuración del estado para Modified está (usando DbContext API):

void UpdateDepartment(Department department) 
{ 
    var dpt = context.Departments.Find(department.Id); 
    context.Entry(dpt).CurrentValues.SetValues(department); 
    context.SaveChanges(); 
} 

CurrentValues.SetValues marca propiedades individuales como Modified.