Transición de EF a ADO.NET

ado.net asp.net-mvc-3 dapper entity-framework

Pregunta

Necesito sugerencias para la migración. Algunos módulos de la aplicación asp.net mvc 3: en este momento estamos usando EF con las clases POCO, pero en el futuro para algunos módulos impulsados ​​por el rendimiento, necesitamos pasar a ADO.NET u otra herramienta ORM (puede ser DAPPER .RED).

El problema al que nos enfrentamos ahora es: nuestros puntos de vista dependen de que las clases de Colección se carguen a través de EF, ¿qué estrategia debo usar para que estas clases de entidades se carguen exactamente de la misma manera que con EF con alguna otra herramienta ADO.NET o ORM? .

Lo que quiero es poder cambiar entre EF y ADO.NET con un mínimo de cambio en la capa de acceso a los datos, ya que no quiero que mis Vistas se vean afectadas por eso.

Respuesta aceptada

Debe utilizar el patrón de diseño del repositorio para ocultar la implementación de su capa de acceso a datos. El repositorio devolverá el mismo POCO y tendrá los mismos contratos de operaciones sin importar la capa de acceso a datos que esté utilizando debajo del capó. Ahora esto funciona bien si está utilizando POCO reales que no tienen métodos virtuales para la carga diferida en ellos. Necesitará manejar explícitamente la carga de colecciones dependientes en entidades para hacer que esto funcione.


Respuesta popular

Lo que he visto hasta ahora, una transición fluida de un ORM / DAL a otro es una ilusión. El patrón de repositorio sugerido por Kevin es de gran ayuda, un requisito previo incluso (+1). Pero, no obstante, cada ORM tiene una huella en la capa de dominio. Con EF probablemente use propiedades virtuales, tal vez anotaciones de datos o, fácilmente olvidadas, un marco de validación que se adapta fácilmente (y descarta otras que no lo hacen). Puede confiar en la capacidad de EF de mapear tablas de unión. Puede haber cosas que no haces (pero te gustaría) hacer por EF.

(Sin mencionar las herramientas que ejecutan andamios sobre un contexto EF. Eso haría que el bloqueo sea aún más estricto).

Algunas cosas que podría hacer en su situación (perdóneme si declaro lo obvio para usted)

  • Use EF de manera óptima. (Mejores asignaciones, mejores asociaciones, ...) Prepararse para el futuro es bueno, pero degenera fácilmente en el patrón YAGNI .
  • Conviértete en un experto en linq + EF: hay muchas formas de matar innecesariamente el rendimiento con EF. ¡Supongamos que EF es lo suficientemente bueno!
  • Siga buscando alternativas de alto rendimiento, como el uso de procedimientos almacenados, paralelización, procesamiento en segundo plano y / o reducción de volúmenes de datos, y elija uno cuando los requisitos (funcionales y no funcionales) sean lo suficientemente claros.
  • Tal vez introduzca una capa de abstracción con DTO que sirva a sus puntos de vista ahora, y en el futuro puede ser materializada fácilmente por otro ORM o ADO.
  • Exponga los POCO como interfaces, que pueden ser implementados por otros objetos más adelante.


Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow
Licencia bajo: CC-BY-SA with attribution
No afiliado con Stack Overflow