¿Cuáles son algunos argumentos CONTRA el uso de EntityFramework? [cerrado]

31

La aplicación que estoy creando actualmente ha estado utilizando procedimientos almacenados y modelos de clase hechos a mano para representar objetos de la base de datos. Algunas personas han sugerido usar Entity Framework y estoy considerando cambiar a eso ya que no estoy tan avanzado en el proyecto. Mi problema es que siento que las personas que defienden EF solo me dicen el lado bueno de las cosas, no el lado malo :)

Mis principales preocupaciones son:

  • Queremos la validación del lado del cliente utilizando anotaciones de datos, y parece que tengo que crear los modelos del lado del cliente de todos modos, así que no estoy seguro de que EF ahorre tanto tiempo de codificación
  • Nos gustaría mantener las clases lo más pequeñas posible al pasar por la red, y he leído que usar EF a menudo incluye datos adicionales que no son necesarios
  • Tenemos una capa de base de datos compleja que cruza múltiples bases de datos, y no estoy seguro de que EF pueda manejar esto. Tenemos una base de datos común con cosas como usuarios, códigos de estado, tipos, etc. y múltiples instancias de nuestras bases de datos principales para diferentes instancias de la aplicación. Las consultas SELECT pueden y consultarán en todas las instancias de las bases de datos, sin embargo, los usuarios solo pueden modificar los objetos que están en la base de datos en la que están trabajando actualmente. Pueden cambiar bases de datos sin volver a cargar la aplicación.
  • Los modos de objeto son muy complejos y a menudo hay bastantes combinaciones involucradas

Los argumentos para EF son:

  • Concurrencia. No tendría que codificar los controles para ver si el registro se actualizó antes de cada guardado
  • Codigo de GENERACION. EF puede generar modelos de clase y POCO parciales para mí, sin embargo, no estoy seguro de que esto realmente me ahorre mucho tiempo, ya que creo que aún necesitaríamos crear modelos del lado del cliente para la validación y algunos métodos de análisis personalizados.
  • Velocidad de desarrollo ya que no necesitaríamos crear los procedimientos almacenados CRUD para cada objeto de base de datos

Nuestra arquitectura actual consiste en un servicio WPF que maneja llamadas a la base de datos a través de procedimientos almacenados parametrizados, objetos POCO que van hacia / desde el servicio WCF y el cliente WPF, y el propio cliente de escritorio WPF que transforma los POCO en modelos de clase con el propósito de validación y El enlace de datos.

Entonces mi pregunta es, ¿es EF adecuado para esto? ¿Hay alguna trampa sobre EF que desconozco?

architecture orm entity-framework Rachel
fuente
Mira esto también ... una comparación de rendimiento y soporte LINQ: ormeter.net
M.Sameer

Respuestas:

7

Recientemente estaba evaluando Entity Framework y el mejor lugar que encontré para problemas y características faltantes fue: http://data.uservoice.com/forums/72025-ado-net-entity-framework-ef-feature-suggestions

Los artículos con más votos:

  1. Soporte para enumeraciones. Este es bastante grande, pero actualmente hay algunas soluciones
  2. Generación de SQL mejorada. La velocidad es realmente importante especialmente para las aplicaciones de nivel empresarial, pero parece que con EF4 ha mejorado mucho
  3. Soporte para múltiples bases de datos. Requisito para cualquier aplicación grande.

Hay muchos más problemas en la lista de Voz del usuario.

En una nota al margen, estoy bastante entusiasmado con el próximo lanzamiento de EF 4.1 que incluirá el enfoque Code-First ... http://blogs.msdn.com/b/adonet/archive/2011/03/15/ef-4 -1-release-candidato-available.aspx

Esto realmente puede empujarme a probar EF en una aplicación de producción.

Mag20
fuente
Argumento en contra: 1 ° y 2 ° y 3 °: ¡¡¡ES LENTO !!! Hay una curva de aprendizaje (necesita saber cómo hacer una unión izquierda; toma 3 horas encontrar una manera de hacerlo para que otra persona sepa lo que se está haciendo ...), paginación en LINQ en lugar de SQL (por ejemplo, feches 10 millones de filas, luego toma 20 de ellas de un desplazamiento arbitrario, y luego te preguntas por qué es tan lento) ... El repositorio no es seguro, debes iniciarlo por consulta, y la inicialización del repositorio es MUY LENTO (como 5 segundos) si tiene una base de datos más grande (eso significa 100-200 tablas, no REALMENTE MUY grande).
Dilema
2
@Quandary Parece que está ejecutando IQueryables (es decir, llamando .ToList()o .ToArray) antes de que sus expresiones LINQ estén completamente definidas. Es por eso que saca todos los registros y lo hace lento.
orad
6

Hacer una ramificación por error / función con EF puede ser notablemente doloroso en el momento de la fusión. Imagine que dos ramas A y B realizan cambios en la base de datos (lo que probablemente sucederá mucho durante las primeras etapas de un nuevo proyecto).

Combina todos los archivos "normales" - archivos cs, etc. Y luego es hora de fusionar Model.edmx. Y de repente no solo está fusionando las asignaciones lógicas entre su modelo de objeto y la base de datos, sino también las posiciones de las tablas en el diagrama de la entidad.

Combinar Model.edmx es tan doloroso que adoptamos una forma bastante desagradable que funciona:

  • Durante la fusión, solo seleccione todas las fusiones de un padre. Lo que no importa; tostará el archivo pronto de todos modos:
  • Revierta Model.edmx a cualquiera de los padres.
  • Migre su base de datos al nuevo estado combinado.
  • Abra Model.edmx y "Actualizar modelo desde la base de datos".
  • Cambie el nombre de todas las propiedades de navegación tostadas durante la fusión.
Frank Shearar
fuente
1
Esta crítica no es válida para EF Code First pero se aplica a Model First y Database First.
Alan Macdonald
Yo mismo creo todas las asignaciones usando Fluent y tomo el control total de la asignación. Estos se colocan dentro de un archivo .cs separado.
Steven Ryssaert
5

Hay un par de otros beneficios para EF que te estás perdiendo:

  • Puede tener una entidad abarcan tablas
  • Puede dividir una tabla en muchos tipos de entidades.
  • Puede generar las entidades desde la base de datos (es decir, la base de datos como enfoque maestro)
  • Puede generar la base de datos desde Entidades (es decir, código como enfoque maestro)
  • Las consultas LINQ se traducen en consultas SQL, mejorando su rendimiento.

Los inconvenientes (especialmente si está utilizando validación):

  • Debe crear un atributo [MetadataClass] que apunte a otra clase que tenga las propiedades que desea validar con los atributos de validación apropiados. Todas las propiedades son objecttipos, por lo que está ahí para leer los metadatos. Todavía hay mucho código extra inactivo.
  • El uso de EntityFramework es un concepto diferente de la forma en que algo como NHibernate (y la versión Java principal también) está diseñado para funcionar. EntityFramework funciona mejor en un modo adjunto donde los objetos usan una conexión en vivo en todo momento. NHibernate y herramientas ORM similares funcionan mejor en modo separado donde la conexión solo se usa al cargar / guardar datos.

Esas son las dos mayores quejas que tengo. Hay una serie de beneficios, pero es muy posible que pueda obtener esos mismos beneficios de NHibernate. Si EntityFramework está sobre la mesa, haga que el equipo también revise NHibernate y haga una rápida revisión de los pros / contras de su proyecto.

El problema de la clase de metadatos es un dolor de cabeza, pero afortunadamente solo tengo tantas entidades que necesitan etiquetas de validación.

La falta de un verdadero modo separado para sus objetos limita lo que puede hacer en un entorno web. El modo adjunto es mejor para aplicaciones de escritorio, que es donde se han originado una serie de innovaciones de Microsoft. El modo separado es posible , pero muy doloroso. Es mejor usar una herramienta alternativa en este caso.

Berin Loritsch
fuente
Su llamado código como enfoque maestro se llama oficialmente código primero
Robert Koritnik
1
@Berin, quiero aclarar lo que quieres decir con "modo adjunto". No creo que Entity Framework tenga una conexión abierta a la base de datos en todo momento. Creo que EF funciona de manera similar a NHibernate en este sentido. ¿Es esto lo que quieres decir o quieres decir algo más? ¿Tiene un enlace a la documentación que explique más este problema adjunto?
RationalGeek
1
Por adjunto, quiero decir que todas sus interacciones con los objetos deben tener lugar dentro de la using(EFConnection conn = new EFConnection)construcción. Si intentas esconder ese objeto en algún lugar para guardarlo de manera segura y puedas hacer una actualización rápida y guardarlo nuevamente en una segunda using(...)declaración, tendrás que pensarlo nuevamente. Consulte msdn.microsoft.com/en-us/library/bb896271.aspx y msdn.microsoft.com/en-us/library/bb896248.aspx . Usar EF 3.5 (que tuve que usar en la última versión) ni siquiera es tan limpio.
Berin Loritsch
Está bien, entiendo lo que quieres decir ahora. Solo quería asegurarme de que la gente no tomara eso como que siempre había una conexión con la base de datos . Debe tener un contexto de objeto que mantenga el estado de las entidades "adjuntas".
RationalGeek
2
Esto no es verdad. EF tiene una fuerte noción de entidades separadas. Una entidad separada debe volverse a unir a su contexto antes de que pueda realizar operaciones relacionadas con el contexto en su contra (como actualizarla en la base de datos). Además, las clases de metadatos solo son necesarias si EF genera sus entidades por usted. POCOs, IMO, son una forma mucho mejor de usar el EF. El uso de POCO simplifica muchas cosas, en particular las pruebas.
Matt Greer
2

Una cosa en la que Microsoft no es muy bueno es en la compatibilidad de comparabilidad con versiones anteriores, especialmente cuando se trata de nuevas tecnologías.

Específicamente, EF1 (.net 3.5) es muy diferente de EF4 (.net 4.0); lo mismo podría ocurrir para la próxima versión.

Esperaría un rato y vería cómo madura la tecnología.

Mientras tanto, considere usar nHibernate: no es equivalente, pero es maduro y se usa de forma salvaje.

Ophir Yoktan
fuente
1
  • Simplemente ... el modelo de dominio rara vez es una réplica del modelo relacional en su base de datos. Por lo tanto, asignar algunas tablas a una clase y tirarlas por cable es simplemente pereza. Las tablas pueden mapearse localmente en 1 objeto a pesar de que la base de datos es de 3 tablas diferentes. Diseña la base de datos de forma inteligente.
  • En segundo lugar, este material EF no puede generar ciertas consultas y tendrá que escribirlas de todos modos.
  • 3º El Modelo de dominio no se asigna directamente a los servicios. Uno solo querrá enviar el conjunto de datos más mínimo a través del cable como DTO ... especialmente, si se va a comunicar con aplicaciones móviles.
  • 5ª capacidad de prueba ... No se pueden crear pruebas suficientemente granulares que proporcionen suficiente regresión contra los cambios de código ... todo para que sea fácil de
    romper ...

Podría escribir una diatriba de 10 páginas. Pero, si solo está escribiendo una aplicación desechable para la Compañía X ... a quién le importa entonces. Pero, si estás desarrollando un producto de software ... vas a tener que ser mucho más anal

usuario104468
fuente
esta publicación es bastante difícil de leer (muro de texto). ¿Te importaría editarlo en una mejor forma?
mosquito del
EF no genera objetos de dominio. Esos son DAO. Deberá utilizar los datos del objeto para crear su objeto de dominio. De todos modos, no debería enviar objetos de dominio desde un servicio, así que cree su DTO más delgado a partir de sus objetos de dominio antes de regresar. EF debería poder generar casi cualquier cosa que pueda expresar en LINQ. La base de datos no es parte de una prueba unitaria, es parte de una prueba funcional. Dicho esto, hay simulacros de memoria disponibles para EF. De lo contrario, abstraiga sus consultas de EF a un repositorio y luego simule eso.
Sinaesthetic
Sí, estoy de acuerdo. Más bien, me refiero a los patrones establecidos por Martin Fowler y Carig Lairman. Al final del día, no puedo usar CTE, PARTITION BY o CROSS APPLY. Tampoco puedo usar un IDataReader que permite mantener baja la sobrecarga de memoria. Además, cuando ejecuto SQL Trace y veo lo que EF envía a través del cable, siento que podría lanzar ;-)
user104468
0

Mira esto: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Los puntos principales son:

  • Falta de carga perezosa
  • Falta de persistencia ignorancia
  • El formato de archivo utilizado para guardar el modelo de entidad contiene elementos de visualización y el modelo de entidad causa problemas de fusión en el entorno del equipo.

Tenga en cuenta que el enlace anterior está hablando de EF1.

También este enlace: http://ormeter.net/ muestra que EF no es el mejor en comparación con otros ORM en rendimiento y soporte LINQ.

M.Sameer
fuente
Tenga en cuenta que esto se publicó cuando EF 1 todavía se lanzó recientemente (o posiblemente aún en versión beta). La situación es mucho mejor hoy con EF 4, y muchas de las cuestiones planteadas en ese voto de desconfianza se han resuelto.
RationalGeek
El último punto todavía cuenta y es muy significativo.
M.Sameer
1
La primera versión de EF fue 3.5. No se han lanzado cuatro versiones principales de EF.
Matt Greer
3
@ Matt, eso es correcto. Pero la versión actual se llama EF 4 para alinearse con el resto de las versiones de .NET 4.
RationalGeek
1
Sin embargo, si es válido o no, no debería afectar el resumen del enlace. Los votos se mostrarán si es válido. :)
Adam Lear