Cuándo NO utilizar Entity Framework

Question

He estado jugando con el EF para ver lo que puede manejar. Además, muchos artículos y publicaciones explican los diversos escenarios en los que se puede utilizar el FE, pero si se pierde el lado "estafa" de alguna manera. Ahora mi pregunta es: ¿en qué tipo de escenarios debería estar lejos del Entity Framework?

Si tiene experiencia en este campo, dígame qué situaciones no funcionan bien con EF. Cuénteme sobre algunos inconvenientes que experimentó en donde deseaba que hubiera elegido una tecnología diferente.

Answer 1

También estoy en el escenario 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 es una solución temporal en una arquitectura de n niveles.

WCF + EF

Si He leído el article correctamente, entonces no veo ningún problema en la serialización de entidades a través del cable (utilizando WCF) y también la ignorancia de la persistencia no es un problema.

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

Prueba de la unidad posible posible! (creo)

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

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

Mi Tuppence Worth

Mi opinión - hacer su propia decisión acerca de la EF y no se deje intimidar por todo el pesimismo con respecto a lo que está haciendo las rondas. Supongo que va a ser por un tiempo y MS resolverá las fallas en el próximo año más o menos. PI definitivamente está llegando de acuerdo con Dan Simmons.

EDIT: Me acabo de dar cuenta de que salté el arma y como un buen político en realidad no respondió la pregunta que se le hizo. Oops. Pero dejaré esto en caso de que alguien más lo encuentre útil.

Answer 2

Un problema potencialmente importante: Entity Framework 1.0 no es compatible con la ignorancia de persistencia. Esto significa que su capa empresarial tiene una dependencia en su capa de acceso a datos.

Si toda su aplicación se alojará en el mismo proceso (como un sitio web en IIS), entonces esto no es un problema.

Si, no obstante, necesita controlar sus entidades (por ejemplo, a un cliente de Silverlight o Windows Mobile), sus entidades no se serializarán fácilmente a través del cable. Tendrá que crear clases de transferencia de datos separadas para enviar sus entidades a través del cable, y una lógica adicional para calcular los datos entre las clases de entidad y los DTO.

Editar: ortografía.

Answer 3

Dado que EF no es compatible con POCO, puede ser difícil escribir buenas pruebas de unidades en contra. Ese fue uno de los golpes en contra en el Vote Of No Confidence.

Si quiere escribir buenas pruebas, EF levantará obstáculos. Puede work around them, pero no es trivial.

Answer 4

No todos los modelos de datos se asignan muy bien a las entidades de la aplicación. Si el mapeo no es relativamente sencillo, omitiría Entity Framework. Te encontrarás haciendo handstand para que funcione sin ningún beneficio claro.

Anders Hejlsberg tenía algunos comentarios interesantes acerca del mapeo objeto/relacional here.

Answer 5

El Vote of No Confidence enumera varios errores y/o faltan bits de funcionalidad a los ojos de aquellos que creen que saben qué características, y sus implementaciones, son adecuadas para 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 con errores que explota a izquierda y derecha. Todas las precauciones en contra de ella son filosóficas. Estoy de acuerdo con el voto de no confianza, pero eso no significa que debas. Si le gusta la forma en que funciona EF, entonces hágalo. Al mismo tiempo, le aconsejo que al menos lea el voto de censura e intente obtener una comprensión rudimentaria de cada uno de los problemas para poder tomar una decisión informada.

Fuera de este problema y en el corazón de su pregunta, debe vigilar el Sql que se está generando para que pueda realizar modificaciones antes de que un problema de rendimiento entre en producción. Incluso si está utilizando procs en el backend, aún buscaría escenarios en los que puede estar golpeando la base de datos demasiadas veces y luego volver a trabajar en sus asignaciones o buscar escenarios en consecuencia.

Answer 6

Aunque tanto SQL CE 3.5 SP1 como Entity Framework 4.0 Beta 1 admiten Columnas de identidad, al usar estos dos productos juntos (al menos hasta las versiones enumeradas), las Columnas de identidad no son compatibles. Deberá configurar las claves principales por su cuenta.

Aparte de eso, he estado disfrutando de EF con SQL CE.