2011-01-31 24 views
15

Estoy utilizando Entity Framework para manipular datos en una base de datos con éxito hasta el momento.Entity Framework - Notificación de cambio de datos subyacentes (en la base de datos)

Sin embargo, me gustaría tener más de una aplicación jugando con los datos al mismo tiempo (edición concurrente).

¿Hay alguna manera de recibir una notificación cuando cambian los datos en la base de datos?

Vi una solución usando el disparador DML, pero me gustaría saber si hay otras formas de lograrlo y, en caso afirmativo, cuál es la mejor solución para usar.

Saludos,

Nic

EDITAR

Tal vez mis preguntas no era lo suficientemente claro, voy a tratar de ilustrarlo con un ejemplo.

  • Aplicación # 1 es el uso de marco de la entidad en la base de datos # 1
  • Aplicación # 2 también está utilizando marco de la entidad en la base de datos # 1
  • Aplicación # 1 cambia el modelo de entidad que se refleja por un cambio en la tabla subyacente de la base de datos n. ° 1
  • Deseo que la aplicación n. ° 2 sea notificada de este cambio para que pueda tener datos consistentes/up2date.
+0

¡excelente pregunta! Mismo problema/pregunta: http://stackoverflow.com/questions/11627959/entity-framework-data-updates-in-a-multi-user-environment-with-central-database – juFo

+0

También tengo el mismo problema –

Respuesta

5

Tal vez deberías pensar en el uso de EF en su aplicación.contexto de EF se debe utilizar para el período tan corto de tiempo como sea posible:

  • Crear contexto
  • Cargar datos
  • datos Modificar
  • Guardar datos contexto
  • gota

Debido implementación interna (IdentityMap, UnitOfWork) el largo contexto de vida no es una buena opción y con un contexto de vida corto no se quiere el comportamiento mencionado al l. Incluso en la aplicación de escritorio debe usar un enfoque como el contexto por formulario. Cargas datos, presentas datos a tu usuario y hasta ese momento solo el usuario puede modificar los datos y presionar el botón Guardar: es responsabilidad de la aplicación lidiar con los problemas de concurrencia de algún modo (marca de tiempo). La modificación automática de los datos que forman parte de la unidad de trabajo en ejecución es una mala idea: ¿qué ocurre si el usuario ya ha modificado los datos? ¿Va a sobrescribir sus cambios?

Editar:

Puede leer más sobre impelementation de ObjectContexthere.

Puedo imaginar situaciones en las que se necesitan notificaciones de actualización de datos para las aplicaciones del cliente. Puede ser de solo lectura de datos en tiempo real, por ejemplo, información de negociación de acciones. Pero en tal caso necesitas algo más poderoso. No es un escenario para que el cliente llame a ORM para obtener datos, sino el escenario para que el cliente se suscriba a algún servicio/nivel intermedio que maneja la recuperación de datos y la notificación de cambios rápidos.

Para escenarios simples donde solo necesita actualizar los datos en tiempo semi-real, puede usar el sondeo: su cliente llamará nuevamente a la consulta en pocos segundos y usará la estrategia StoreWins. Cualquier estrategia de notificación queda fuera del alcance de EF: debe implementarla como desencadenante, dependencia de sql, patrón de suscripción de publicación u otra cosa. Incluso con la notificación, solo podrá manejar algún evento y volver a consultar los datos.

De nuevo, si desea reducir la transferencia de datos con el sondeo, necesita algún servicio/nivel intermedio que permita cierto nivel de almacenamiento en caché (también puede probar los Servicios de datos WCF).

+0

Esta respuesta está completamente fuera del tema. Su respuesta de sondeo es exactamente por qué se formula la pregunta. Para evitar el sondeo. –

+0

https://code.msdn.microsoft.com/How-to-use-SqlDependency-5c0da0b3 –

2

En la base de datos, puede poner una columna timestamp en su tabla y usarla para indicar si una fila se ha actualizado desde la recuperación. Esto podría verificarse mediante un desencadenante como usted sugiere, o mediante un sistema de monitoreo en su código C#, o si solo desea evitar la sobreescritura de cambios, puede escribir actualizaciones que verifiquen las marcas de tiempo y las use para guardar sus entidades.

Independientemente de la opción que elija, tendrá que decidir de antemano cómo desea gestionar los conflictos.

Timestamp-based concurrency control

+1

+1 para el mejor enfoque aquí. TIENE que usar la marca de tiempo, ese es el mejor enfoque para las comprobaciones de concurrencia y ahora EF 4.2 lo admite automáticamente. –

0

No sé qué proveedor usted utiliza. De todos modos, tanto Devart como ODP admiten la notificación de DB. Para Devart puede ver el siguiente enlace OracleDependency Class

Cuestiones relacionadas