Cuando NO usar el Entity Framework

.net architecture c# entity-framework

Pregunta

He estado jugando con el EF para ver qué puede manejar. También muchos artículos y publicaciones explican los diversos escenarios en los que se puede utilizar el EF, sin embargo, si se pierde el lado "con" de alguna manera. Ahora mi pregunta es, ¿en qué tipo de escenarios debo mantenerme alejado del Entity Framework ?

Si tiene alguna experiencia en este campo, dígame qué escenarios no juegan bien con el EF. Hábleme de algunas desventajas que experimentó cuando deseaba haber elegido una tecnología diferente.

Respuesta aceptada

También estoy en la etapa de 'jugar', y aunque estaba preocupado por la falta de agnosticismo de persistencia incorporado, estaba seguro de que habría una "solución alternativa".

De hecho, ni siquiera una solución alternativa en una arquitectura de n niveles.

WCF + EF

Si he leído el artículo correctamente, entonces no veo ningún problema al serializar entidades a través del cable (usando WCF) y también la ignorancia de la persistencia no es un problema.

Esto se debe a que usaría PI principalmente para pruebas de unidad.

La prueba de unidad es posible! (Yo creo que)

En este sistema, simplemente podríamos usar un servicio simulado (envolviendo la llamada al servicio en OTRAS clases basadas en interfaz que podrían producirse desde una fábrica, por ejemplo). Esto probaría NUESTRO código de presentador (no es necesario realizar una prueba unitaria del EF / DAL, ¡ese es el trabajo de Microsoft!) Por supuesto, las pruebas de integración aún serían necesarias para alcanzar la plena confianza.

Si quisiera escribir en una base de datos separada, esto se haría en la capa DAL, que se lograría fácilmente a través del archivo de configuración.

Mi Tuppence Worth

Mi opinión: decida usted mismo sobre el EF y no se deje intimidar por toda la pesimismo que lo rodea. Supongo que será por un tiempo y MS esclarecerá las fallas en el próximo año más o menos. PI definitivamente viene de acuerdo con Dan Simmons.

EDITAR : Me acabo de dar cuenta de que salté el arma y, como un buen político, en realidad no contesté la pregunta que se hizo. Ups. Pero lo dejo en caso de que alguien más lo encuentre útil.


Respuesta popular

El Voto de No Confianza enumera varios errores y / o partes faltantes de funcionalidad a los ojos de aquellos que creen que saben qué funciones y sus implementaciones son adecuadas para los marcos ORM / Datamapper.

Si ninguno de esos problemas es importante para usted, entonces no veo por qué no debería usarlo. Todavía tengo que escuchar que es un desastre de buggy que explota a izquierda y derecha. Todas las advertencias en contra son filosóficas. Resulta que estoy de acuerdo con el voto de no confianza, pero eso no significa que debas hacerlo. Si te gusta la forma en que EF funciona, entonces hazlo. Al mismo tiempo, le aconsejo que al menos lea el voto de no confianza y trate de obtener una comprensión rudimentaria de cada uno de los temas para tomar una decisión informada.

Fuera de ese problema y en el corazón de su pregunta: debe mantener un ojo en el Sql que se está generando para poder hacer ajustes antes de que un problema de rendimiento entre en producción. Incluso si está utilizando procs en el backend, buscaría escenarios en los que podría estar golpeando la base de datos demasiadas veces y luego volver a trabajar sus asignaciones o buscar escenarios en consecuencia.



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é