Linq2SQL vs EF en .net Framework 4.0

Question

¿Cuál es el veredicto sobre estos dos productos ahora? Parece que no puedo encontrar nada sobre este tema ESPECÍFICAMENTE para VS2010/.net 4.0

Detrás en .net 3.5 días, la mayoría de la gente cree que Linq2SQL estará muerto cuando aparezca .NET 4.0, pero parece estar vivo y bien.

Por otro lado, EF 4.0 parece haber mejorado significativamente.

Para mí, la mayor parte de mi trabajo hasta el momento son proyectos pequeños a medianos, y mi empresa está migrando de VS08 a VS10 pronto. ¿Qué debería estar mirando? O realmente, ¿debería pasar el tiempo estudiando EF4.0 o sería más tiempo dedicado a mirar nHibernate? (Pero volviendo al tema, estoy realmente más interesado en Linq2Sql - EF.)

Por último, actualmente estoy usando entlib/unity, ¿qué marco es más amigable para la inyección de dependencia/política?

Gracias de antemano.

Answer 1

Estas son algunas razones por las Entity Framework (v4) es mejor:

1 - L2SQL es esencialmente obsoleto

2 - L2SQL no soporta POCO mapeo, EF hace.

3 - EF tiene más flexibilidad (código primero, modelo primero, base de datos primero). L2SQL tiene solamente 1.

4 - EF tiene soporte para sproc -> POCO mapeo

5 - EF tiene Entidad-SQL, lo que le permite volver a ADO.NET clásico cuando se requiera

6 - EF soporta herencia (TPT, TPH)

7 - EF va mano a mano con el patrón de repositorio, y ejecución diferida a través de IQueryable

8 - componentes EF (ObjectSet, ObjectContext) son fácilmente mockable y permitir DI

No puedo pensar en ninguna razón por la cual los nuevos proyectos deberían usar L2SQL.

Algunos podrían decir "Bueno, L2SQL es bueno para proyectos pequeños, puedo arrastrar y soltar y terminar con eso".

Bueno, también puedes hacerlo con EF4, y tendrás más flexibilidad/soporte a largo plazo si decides modificar/hacer crecer tu proyecto. Entonces eso no es una excusa.

HTH

Answer 2

Acabamos de pasar de VS 2008 a VS 2010 y de L2S a EF.

Aunque utilizamos EF de forma muy similar a L2S, me consuela saber que tengo flexibilidad para realizar un ORM más avanzado en caso de necesidad.

Dicho esto, para un proyecto pequeño, probablemente todavía use L2S. Proyectos medianos a grandes Yo usaría EF.

También - EF parecía una gran curva de aprendizaje, porque la documentación de EF nos llevó a comenzar a investigar algunos patrones de diseño como la Unidad de trabajo, Depósito, Inyección de dependencia. Sin embargo, me di cuenta de que estos patrones se aplicaban tanto a L2S como a EF.

En términos de Nhibernate, mi investigación (es decir, navegación SO) indica que la última versión de EF4.0 es lo suficientemente avanzada (soporte POCO, etc.) para ser considerada un producto competitivo.

Answer 3

L2S no irá a ninguna parte. El equipo de VS lo dejó en claro. No obtendrá una mejora significativa, pero aún estará disponible y funcionará perfectamente.

L2S es excelente y fácil de usar para proyectos a pequeña escala con modelos de datos bastante simples. El desencadenante para mí, cuando elegir EF sobre L2S es si tengo tablas de muchas a muchas, o tengo que mapear entidades más complejas en más de una sola tabla.

Answer 4

sólo para añadir a las respuestas y los comentarios anteriores (los tres tiene un voto 1 de mí):

a) Rendimiento: el tiempo de ejecución L2S es más ligero que EF (debido a que solo una sola capa ; EF tiene que tratar con dos capas de modelo y las asignaciones entre ellas).

EF a menudo genera un poco más detallado de TSQL que L2S, pero la mayoría de las veces eso solo afecta la legibilidad si está creando perfiles y mirando las consultas generadas; el optimizador de SQL terminará con el mismo plan de ejecución más del tiempo. Sin embargo, hay algunos casos en los que las consultas pueden crecer tanto y ser tan complejas que pueden tener un impacto en el rendimiento.

L2S también es un poco mejor a la hora de hacer consultas de optimización del lado del cliente; elimina los predicados de cláusulas que pueden evaluarse en el lado del cliente, por lo que la base de datos no tiene que preocuparse por ellos. Esto significa menos trabajo para el optimizador de SQL Server, y menos riesgo de que termine con un plan de ejecución "malo".

b) L2S vs L2E: L2S todavía es ligeramente mejor que L2E en la traducción de las consultas LINQ que utilizan métodos de CLR normales en TSQL, especialmente cuando se trata de DateTime y métodos relacionados con ella. L2E admite más o menos las mismas cosas, pero a través de su propia clase EntityFunctions: http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.

Tanto L2S y EF son excelentes opciones en mi opinión, escoger el que se sienta cómodo y cubre las cosas que necesita ahora y durante la vida útil razonable del código que está escribiendo. Antes de que te des cuenta, Microsoft probablemente anuncie otra tecnología de acceso a datos. Parecen hacer eso cada 3-5 años ... :) DAO, RDO, ODBC, ADO, OLEDB, ADO.NET, conjuntos de datos tipeados, ObjectSpaces, WinFS, L2S, EF, ... etc. Código que escribí 15 Hace años que DAO todavía está disponible, en aplicaciones que todavía están en el mercado, y todavía funciona a pesar de que DAO estuvo "muerto" durante años.

veces los nombres son reutilizados por completo las nuevas tecnologías de acceso a datos, pero eso no cambia el hecho de que todo lo que constituye la última tecnología de acceso de base de datos de Microsoft es un objetivo en constante movimiento ...

Answer 5

Si los productos de terceros son apropiados para usted, intente usar LinqConnect. Este producto le permite usar Linq a SQL (con algunas modificaciones) con diferentes DBMS (Oracle, MySQL, PostgreSQL, etc.).
LinqConnect le ofrece las siguientes características no disponibles en L2S anterior:

• -Modelo Primera aproximación
• TPT y TPH soporte de apoyo
• POCO
• la sincronización automática de modelo y base de datos sin pérdida de datos.

En cuanto a rendimiento, la última prueba comparativa en OrmBattle nuestro proveedor se encuentra entre los líderes.

Además, todas las funciones de EF se admiten en nuestro DBMS-specific providers también.

Answer 6

Sé que esto es probablemente demasiado tarde para que la consulta original, pero por el bien de la gente del futuro con una pregunta similar ...

En mi opinión, el aspecto crucial es si usted está haciendo una nueva proyectar o trabajar con un DB heredado. Estoy trabajando con un DB heredado, con algunas decisiones de diseño bastante idiosincrásicas. Me gustaría utilizar EF, pero simplemente no logró mapear estas idiosincrasias, mientras que L2S se manejó perfectamente bien.

Por ejemplo. Algunos de los FK contenían otros valores además de las claves de las filas relacionadas, duplicándose de forma efectiva como una columna FK/flag. Además, el mapeo de herencia FK falló totalmente en contra de DB, así que opté por un modelo L2S plano, para obtener los beneficios de comprobación de tipos y comprobación de nombres en tiempo de consulta, pero terminé construyendo mi propia capa de mapeo.

Todo esto es un dolor horrible, si es un consuelo para MS, también encontré a NHibernate incapaz de la tarea. En mi experiencia, en el uso del mundo real, demasiados DB tienen este tipo de problemas, de ahí mi recomendación de que EF no es realmente adecuado para el desarrollo de campo pardo.

Para nuevos proyectos, tiene el lujo de evolucionar su diseño de base de datos para que coincida con las suposiciones del marco. No puedo hacer eso ya que las aplicaciones existentes dependen del diseño de datos. Esperamos mejorar el diseño gradualmente, pero intentar corregir todos los problemas desde el principio daría como resultado un evento de migración inadmisiblemente grande (para nuestros recursos).

Nota: En el Reino Unido (al menos), el desarrollo del campo marrón está construyendo casas en terrenos que se han desarrollado previamente. El desarrollo del campo verde se basa en nuestros recursos menguantes del campo. He reutilizado los términos aquí.