Marco de la entidad: ¿por qué establecer explícitamente el estado de la entidad como modificado?

La documentación oficial dice que para modificar una entidad, obtengo un objeto DbEntityEntry y trabajo con las funciones de propiedad o establezco su estado en modificado. 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 pregunto al marco por una entidad como la primera statement, y luego modifico el POCO como en

 dpt.Name = "Blah" 

Si luego le pido a EF SaveChanges (), la entidad tiene un estado de MODIFICADO (supongo que a través del 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?

En su escenario, de hecho no tiene que establecer el estado. El objective 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).

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 configurar el estado en Modified (y estoy seguro de que Ladislav era consciente de esto, pero aún así me gustaría señalarlo aquí).

  1. Todos los campos en el registro serán actualizados, 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 con OK .

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

De todos modos, la alternativa a establecer el estado en Modified es (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 .