2010-09-22 13 views
20

He leído muchas quejas sobre Entity Framework en .NET 3.5 SP1, especialmente sobre su SQL generado ineficazmente. Esas quejas me habían impedido estudiar Entity Framework.Entity Framework 4.0: ¿vale la pena ahora?

Ahora ha salido Entity Framework 4.0, que ofrece muchas promesas. Me pregunto si realmente es un buen ORM ahora, o todavía no? ¿Vale la pena aprender y usarlo en mis proyectos .NET, en lugar de las consultas SQL tradicionales? ¿Planeaste cambiar a EF 4.0 todavía?

Gracias de antemano.

+0

Supongo que probablemente dependa del DBMS al que desee apuntar –

+0

@vc 74, en realidad, EF no mapea la mayoría de los DBMS que existen. No puse esto como una respuesta, pero creo que EF 4.0 es una mejora importante. Estaba a punto de cambiar a nHibernate después de mucha frustración con EF 3.5, pero lo probé. –

+1

debe ser CWiki. – RPM1984

Respuesta

8

Realmente debería comprobar Julie Lerman's blog on EF4, ella es a la vez entusiasta en el producto, pero técnicamente correcta. Según yo, puedo decirte que ya hemos usado EF4 en más de un par de proyectos de producción con buenos resultados :-)

+0

Gracias ___ lo entendieron bien ... esa cosa de .NET 3.5 fue horrible. – kape123

8

Una palabra: ¡SÍ!

Entity Framework 4.0 contiene una gran cantidad de adiciones y mejoras, y con las plantillas adicionales para POCO y entidades de auto-seguimiento, definitivamente está listo para el horario estelar.

Si lo desea, puede incluso definir su "modelo" completo de EF en el código - no * .edmx en absoluto - se parece y se siente mucho a Fluidez NHibernate. Tiene muchas opciones con EF4, y eso es una buena señal, y una señal de que el equipo de ADO.NET realmente escuchó a la comunidad (y trabajó mucho para hacer que esas cosas mejoren mucho ahora).

Además del libro y el blog de Julie Lerman, también debe consultar el ADO.NET EF4 team blog, que contiene consejos y sugerencias muy útiles y útiles.

Esta entrada de blog en particular, podría ser de interés para usted:

+1

+1 - Acepto ... – KristoferA

+1

* "... incluso puede llegar a definir su" modelo "de EF completo en el código - archivo * .edmx en absoluto ..." * Solo para aclarar, como de hoy, solo está disponible como CTP y será una característica estándar de EF 5.0. –

+0

Sí, el enfoque de "codificar primero" es un CTP por ahora, pero podría aparecer en VS 2010 SP1 - EF 4.0 SP1 :-) –

2

, EFv4 (en .NET 4) está en una liga completamente diferente a EFv1 (en .net 3.5 SP1).

EFv1 tenía muchas limitaciones y a veces generaba T-SQL horrible.

El TSQL generado por EFv4 está bien por lo que a mí respecta; a veces tiene un poco más de anidamiento con subconsultas que las necesarias, pero eso es algo cosmético que solo afecta la legibilidad humana ...

1

Si necesita ORM y está limitado a .NET Framework entonces sí EF v4.0 es una actualización importante y es mucho mejor que EF v1. Pero, por otro lado, sigue siendo solo una segunda versión y todavía no se resuelven muchos problemas. También el primer desarrollo del código mencionado (no .edmx) es solo la versión CTP que no está lista desde el uso de la producción. Pero creo que puedes usar EF con éxito en cualquier tipo de proyecto y aún obtendrás un valor agregado en un desarrollo más rápido.

Entre las limitaciones se puede pensar:

  • asignaciones limitadas
  • peor experiencia con EDMX en entorno compartido
  • mala experiencia en escenarios desconectados
  • Sin acumulación en la localización de
  • extensibilidad limitada , sin ganchos
  • etc.
0

Sin por ahora

Teniendo en cuenta las limitaciones y experiancia anterior con EF en 3.5 SP1, sugeriría no considerar EF hasta que stabilises.May sea por la versión 5, que debería supppose. Sería mejor si continúa con su diseño de LinQ a SQL hasta entonces.

Programación feliz ...

+0

¿Le ha echado un buen vistazo a EF4? Casi todo el problema de la versión v1/v3.5 ya está resuelto y ya no es un problema ..... –

+0

está hablando de EF4 no EF que se lanzó con 3.5 –

+2

@marc Por qué sugerí esperar hasta que EF5 esté porque tenía muchos problemas solo por adoptar EF con 3.5sp1. Es cierto que no le he dado una buena mirada a EF4 ya que estaba un poco asustado con mi experiencia previa. Así que desde los mensajes tengo una sensación positiva hacia EF4 y voy a intentarlo definitivamente. –

1

EF4 sigue desaparecido componentes muy importantes. Sin embargo, ¿por qué estás esperando el producto perfecto? Nunca va a estar cerca. EF4 es bastante útil incluso si tiene algunos bordes ásperos.

Puede usar SQL y EF4 uno al lado del otro, de modo que si se topa con un escenario en el que EF4 crea un código ineficiente o simplemente no admite algo, siempre puede usar el antiguo ADO.NET. El marco de entidad en realidad admite la construcción de entidades a partir del DataRow s, por lo que puede fácilmente volver a conectar los resultados de una consulta SQL tan excepcional al flujo de programa normal. Donde EF4 brilla se encuentra en los escenarios más normales donde entra en juego el intellisense de seguridad de tipo &.

El uso del marco entidad implica un poco de una curva de aprendizaje, y cuanto antes comience, mejor. A pesar de el hecho de que EF4 aún no está allí (en mi opinión, de todos modos), diría: ¡adelante! Úselo para algunos rincones pequeños de su aplicación para tener una idea.

puede construir un conexión de la entidad a través de una (sin abrir) SqlConnection existente que se abre por el EntityConnection, y el uso de TransactionScope permite entonces que comparta una sola transacción no distribuida entre EF y ADO. Tomados en conjunto, eso significa que puede usar pequeños bits de EF como reemplazos para consultas normales de ADO, transacciones y todo, como parte de la misma conexión (es decir, sin gastos adicionales desde la perspectiva del servidor).

+0

¿Qué "componentes principales"? ¿Te importa elaborar un poco más? –

+0

En resumen: mira las otras publicaciones. Mi punto es que las limitaciones (que existen) no son motivo suficiente para dejar pasar las ventajas (que también existen), ya que es bastante factible usarlas junto con ADO. Algunas limitaciones son la falta de POCO, soporte de diseñador limitado, falta de actualizaciones de lotes, mala integración con vistas, falta de soporte para operaciones "no esenciales" (por ejemplo, INSERTAR O IGNORAR), y por lo tanto, rendimiento subóptimo en escenarios de actualización. Ah, y la API es demasiado compleja en materia de control de versiones de entidades. De todos modos, la mayoría de estos no son problemas para el 95% de todas las consultas, y está bien utilizar la extraña alternativa. –

1

No. EF no es compatible con System Conceptual Integrity (ni arquitecturas de n niveles), por lo que no tendrá arquitectura sino un conjunto de componentes con referencias caóticas, una plataforma incorrecta con mecanismos de comunicación incorrectos.