¿Cuál es su opinión sobre el Entity Framework?

Question

He oído algunas cosas malas sobre Entity Framework, y estoy considerando su uso.

• ¿Cuál es su opinión al respecto?
• ¿Debo aprenderlo?
• ¿Cuáles son sus puntos fuertes?
• ¿Cuáles son los puntos débiles de esto?

Answer 1

Si nunca ha utilizado ningún tipo de entidad comercial u O/RM (como NHibernate o LLBLGen), probablemente no encontrará muchos inconvenientes con Entity Framework. En mi empresa evaluamos las 3 herramientas y terminamos eligiendo LLBLGen porque era una manera muy fácil de trabajar directamente con la base de datos (en lugar de perder mucho tiempo creando un modelo de objetos).

Por alguna razón, era más fácil para nosotros comenzar con nuestro modelo de datos y compilación (el enfoque LLBLGen y EF), en lugar de comenzar con un modelo de objetos como lo haría con NHibernate. Mi equipo realmente no podía "obtener" Entity Framework ... parecía más difícil trabajar con LLBLGen.

tomar esto con un grano de sal ... evaluamos los 3 herramientas para unos pocos días, por lo que nuestra experiencia con EF y NHibernate no es particularmente profunda.

Answer 2

le sugiero que tome un vistazo a https://stackoverflow.com/questions/tagged/entity-framework para obtener más información acerca marco de la entidad y cómo se compara con otras herramientas.

Answer 3

Estoy teniendo un tiempo horrible con el nuevo marco de la entidad 4. Debido a un pequeño problema con la concurrencia. El problema real con Entity Framework es: - No hay sitio web normal para darme respuestas o publicar mis problemas - No hay buena documentación para buenas prácticas - No hay tutoriales para buenos conceptos básicos para hacer cosas con él (la única dimensión Todo el mundo ABM es la publicación en Internet son bastante inútil)

Y, finalmente, como la mayoría de ORM: es difícil conseguir que funcione de la manera que lo necesite

Answer 4

Michel - lo que específicamente es que los problemas de concurrencia? Estamos en el proceso de evaluar EF para un gran proyecto que está a punto de comenzar. Tenemos experiencias pasadas que utilizan ORM en proyectos grandes (LLBLGen), pero estábamos buscando el ORM nativo de @MS a través de EF. Cualquier información sobre sus puntos de dolor sería útil.

Puede encontrar información detallada bastante aquí: http://msdn.microsoft.com/en-us/library/aa697427(VS.80).aspx

En cuanto a la pregunta original: Definitivamente creo que vale la pena aprender EF, ya que muy probablemente vamos a escuchar de él durante años. Incluso si su equipo/compañía no lo está usando en este momento, es probable que esté en nuestras vidas en el futuro ... por lo que en mi opinión es bueno investigar cualquier cosa que esté por venir y que nos rodee.

He pasado cerca de 10 horas evaluando en este momento y esto es lo que he encontrado:

• ¿Cuál es su opinión al respecto? - hasta ahora la versión 4 parece cumplir con las características de ORM aceptables mínimas.

• ¿Debo aprender? - en mi opinión sí. por favor mira mis comentarios arriba.

• ¿Cuáles son sus puntos fuertes? - soporte nativo de herramientas en VS

• ¿Cuáles son los puntos débiles de esto? - Estoy de acuerdo con el otro afiche en que otras herramientas ORM pueden ser mucho más fáciles. He estado usando LLBLGen durante aproximadamente 4 años. Recuerdo que tenía una curva de aprendizaje steap, pero por alguna razón no parecía tomar mucho tiempo en absoluto.

• Im encontrando la falta de fuertemente tipado incluye + ayuda para el recorrido del modelo en el incluye es un poco débil.

• También en la versión anterior, la falta de soporte para los FK hizo que EF no fuera muy útil en mi opinión.

Answer 5

Aquí la premisa básica:

Desarrolladores pasan demasiado tiempo en la capa de datos, la escritura del sql, preocuparse por la base de datos, etc. ¿Por qué no dejar que un marco hacerse cargo de esto. No te preocupes por los detalles.

Esta es la premisa de Entity Framework y otros ORM para el caso.

Algunas de las cosas buenas de Entity Framework:

Modelado Sin inserto tedioso, actualizar el tipo de cosas, escribir menos código objetos seguimiento de cambios Etc. (hay otros, puede ir al sitio de Micorsoft detalles)

Pero en mi humilde opinión, los desarrolladores deberían preocuparse por los detalles.

Después de todo, eres un desarrollador, ¿verdad? Esto es especialmente cierto si la base de datos de la aplicación está centrada.

Muchas de las "actividades de caja mágica" suceden con estos marcos. Son generadores de código. Generan muchos SQL para hacer las inserciones, actualizaciones, etc. cuando se ejecutan si no se usan SP directamente. Cuando las cosas van hacia el sur (rendimiento, memoria, etc.) ¿cómo se abre la caja mágica? También tienes que aprender los pormenores de cómo funciona la caja mágica. A veces hace cosas que no esperarías.

Por lo tanto, mi opinión es que Entity Framework es útil, pero ten cuidado con el comprador.

Creo que sería más útil para proyectos más pequeños cuando tenía un modelo de datos sencillo y necesitaba hacer las cosas rápidamente y realmente no quería perder tiempo escribiendo SQL o jugando con el DAL.

Si está construyendo una aplicación grande que es el corazón de su negocio, creo que es mejor pasar el tiempo por adelantado para aprender y hacer todo el acceso a los datos, porque cuando hay problemas (y habrá problemas), podrás profundizar y descubrir la solución. También la mayoría de las aplicaciones principales duran muchos años. Estos marcos probablemente tengan una vida útil más corta que las aplicaciones principales en su negocio.

Answer 6

Microsoft está estableciendo una estrategia incorrecta en mi opinión. El resultado de alentar a los Desarrolladores (especialmente a los novatos) a utilizar EF en lugar de aprender SQL es que termina en Aplicaciones mal diseñadas con pérdidas potenciales de rendimiento. He visto el código C# repartido en más de 200 líneas, lo que podría haberse escrito en 3 líneas SQL.

Ese es el principal problema que veo en O/R Mappers, la falta de comprensión de SQL. Llámame vieja escuela ;-)