Entity Framework CTP 5 - Patrón de depósito - haciendo actualizaciones

Question

¿Cómo harías una operación de actualización con CTP 5 usando DbContext y usando el patrón Repository? Anteriormente con EF 4.0, se podría hacer como a continuación.

_context.Customers.AddObject(item); 
_context.ObjectStateManager.ChangeObjectState(item, System.Data.EntityState.Modified); 

¿Hay alguna razón de por qué EF no proporciona una manera fácil de actualizar las entidades "desconectadas". No deseo consultar el archivo db y copiar todas las propiedades al objeto que se devuelve desde la consulta. En otras palabras, EF debe tener un método de actualización que tome en la entidad (similar al método Add). Si la clave de entidad ya existe en la base de datos, actualice la entidad con los valores actuales. es decir, ¿por qué deberíamos hacer "Adjuntar" y luego copiar todas las propiedades al objeto adjunto. Para mí, parece redundante copiar todas las propiedades de las entidades solo para actualizar cuando el objeto "desconectado" ya existe.

Answer 1

creo que todavía se puede realizar el mismo método que en el ejemplo de código para actualizar una entidad desconectado con el CTP5 DbContext:

_dbContext.Customers.Add(item); 
DbEntityEntry entry = _dbContext.Entry(item); 
entry.State = EntityState.Modified; 

_dbContext.SaveChanges(); 

Mirando el SQL generado esto crea por supuesto, una instrucción de actualización completa en todos propiedades del objeto del cliente, incluidas las propiedades que en realidad no cambiaron, ya que EF no sabe cuál es el estado actual en la base de datos. Si se quiere evitar que, supongo que no hay otro camino que ir a buscar el estado actual en la base de datos antes de la actualización que podría hacerse de esta manera:

DbEntityEntry entry = _dbContext.Entry(_dbContext.Customers.Find(item.ID)); 
entry.CurrentValues.SetValues(entity); 

_dbContext.SaveChanges(); 

(Asumiendo que aquí se tiene una clave ID de su cliente objeto "elemento").

Esto crea una declaración de actualización SQL que solo incluye las propiedades que de hecho han cambiado en comparación con el estado en la base de datos. No estoy seguro de si la segunda forma es necesariamente la opción de menor rendimiento debido a la declaración de selección adicional. Si el tipo de objeto es grande pero solo unas pocas propiedades han cambiado, la sobrecarga de enviar una declaración de actualización completa en todos los campos puede ser mayor que una declaración de selección más una declaración de actualización "pequeña" con solo los campos que realmente se requieren para la actualización. (Pero eso es solo especulación, no soy un especialista de SQL Server.)