Pregunta

Recién empezando a probar EF6 y sus funciones asíncronas. Me sorprendió cuando me di cuenta de que no estaban a salvo de hilos. Supuse que ese era el punto.

Ya tenía años mis propios métodos de extensión basados ​​en Task , pero lo que estaba esperando de EF era hacerlos seguros para los hilos.

Al menos mis funciones basadas en tareas se lock para no interferir entre sí. EF6 ni siquiera llega tan lejos. Pero el problema principal es algo que mi código comparte con el de ellos. es decir, intente emitir una consulta asíncrona y luego, antes de que se complete, intente acceder a una propiedad de navegación (en una entidad totalmente separada precargada en el mismo contexto) que activa la carga perezosa. Esto podría ser activado ya sea por la UI, o por otro código fuera de la función inmediata, o por una docena de otros escenarios.

Por lo que yo puedo decir. Los únicos dos recursos mutables compartidos (entre entidades) en un dbContext son la conexión y el seguimiento de cambios (almacenamiento en caché). Si pudiéramos agregar el bloqueo a las funcionalidades, tendríamos un contexto seguro para subprocesos.

Incluso podríamos hacerlo en dos etapas. Si pudiéramos implementar un proveedor que bloquee la función centralizada utilizada para consultar la base de datos. Entonces, cualquier consulta no rastreada, ya sea devolviendo objetos sin entidad (anónimos) o llamando a AsNoTracking (), sería segura para subprocesos y sería segura para llamar con funciones asíncronas incluso cuando otro subproceso esté pidiendo un objeto cargado perezoso.

Nuestra escalabilidad no sería peor que ahora, ahora que tenemos que usar un contexto por subproceso, e incluso las funciones Async están fuera de la tabla si intenta omitir incluso uno que espera introducir un poco de paralelismo o está trabajando en un evento Sistema (como wpf) que podría activarse una vez que la función esperada regrese con la tarea.

Así que mi pregunta es. ¿Alguien ha implementado un proveedor como este? ¿O alguien estaría dispuesto a trabajar conmigo en ello?

Respuesta popular

Creo que te enfrentas a un problema arquitectónico. Lo que describe es una aplicación en la que la IU usa directamente los objetos de EF y rompe el paradigma de "separación de preocupaciones".

Por mi parte, utilizo cachés de aduana seguros para subprocesos en una capa de Modelo, dejando que todo suceda en la capa de Modelo. Implementé la seguridad de subprocesos en mi caché con el conocido AsyncLock.

Los objetos DbContext y todas las operaciones relacionadas con EF CRUD tienen una vida útil muy limitada. Cada operación de CRUD crea una instancia de su propio DbContext, y devuelve objetos de modelo a la memoria caché, luego, los contextos se recolectan como basura. Mis aplicaciones usan cachés como capa de abstracción, y cachés usa EF como capa de abstracción DB.

Por ejemplo, la exploración de propiedades adjuntas en Objetos, se realiza mediante la implementación de métodos personalizados en la capa Modelo, que toma la identificación del objeto como parámetro y devuelve una lista de objetos relacionados a la memoria caché. La interfaz de usuario solicita la memoria caché, luego la memoria caché solicita a EF y, una vez que está disponible, la llamada realizada a la memoria caché devuelve los objetos a la interfaz de usuario. Simple como eso.

EntityFramework no está diseñado para ser seguro para subprocesos, por lo que no hay forma de trabajar con él de manera múltiple. ( EF hilo de seguridad )

En lugar de tener acceso paralelo a su DbContext, debe crear una capa de modelo a la que se pueda acceder de forma múltiple. Y su modelo puede hacer múltiples llamadas paralelas a su base de datos, pero tenga en cuenta que cada llamada debe crear una instancia y mantener su propio DbContext. Al final de cada llamada, el DbContext relacionado debe ser eliminado.

Los DbContext son realmente rápidos de instanciar, el único inconveniente es la latencia de la red. Es por eso que una memoria caché es una buena idea.




Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
¿Es esto KB legal? Sí, aprende por qué