Entity Framework vs LINQ to SQL

Ahora que se ha lanzado .NET v3.5 SP1 (junto con VS2008 SP1), ahora tenemos acceso al marco de la entidad .NET.

Mi pregunta es esta Al tratar de decidir entre usar Entity Framework y LINQ to SQL como ORM, ¿cuál es la diferencia?

Según tengo entendido, el Entity Framework (cuando se usa con LINQ to Entities) es un 'gran hermano' para LINQ to SQL. Si este es el caso, ¿qué ventajas tiene? ¿Qué puede hacer que LINQ to SQL no pueda hacer por sí solo?

LINQ to SQL solo admite el mapeo 1 a 1 de tablas de base de datos, vistas, sprocs y funciones disponibles en Microsoft SQL Server. Es una gran API para usar para la construcción de acceso rápido a datos en bases de datos SQL Server relativamente bien diseñadas. LINQ2SQL se lanzó por primera vez con C # 3.0 y .Net Framework 3.5.

LINQ to Entities (ADO.Net Entity Framework) es una API ORM (Object Relational Mapper) que permite una definición amplia de modelos de dominio de objetos y sus relaciones con muchos proveedores de datos ADO.Net diferentes. Como tal, puede mezclar y combinar diferentes proveedores de bases de datos, servidores de aplicaciones o protocolos para diseñar una combinación agregada de objetos que se construyen a partir de una variedad de tablas, fuentes, servicios, etc. ADO.Net Framework fue lanzado con .Net Framework 3.5 SP1.

Este es un buen artículo introductorio sobre MSDN: Introducción de LINQ a los datos relacionales

Creo que la respuesta rápida y sucia es que

• LINQ to SQL es la forma rápida y fácil de hacerlo. Esto significa que comenzará más rápido y entregará más rápido si está trabajando en algo más pequeño.
• Entity Framework es la forma total de hacerlo sin restricciones. Esto significa que tomará más tiempo por adelantado, se desarrollará más lentamente y tendrá más flexibilidad si está trabajando en algo más grande.

¿LINQ to SQL está realmente muerto? por Jonathan Allen para InfoQ.com

Matt Warren describe [LINQ to SQL] como algo que "nunca se suponía que existiera". Esencialmente, se suponía que debía ser suplente para ayudarlos a desarrollar LINQ hasta que el ORM real estuviera listo.

...

La escala de Entity Framework hizo que perdiera la fecha límite de .NET 3.5 / Visual Studio 2008. Se completó a tiempo para el lamentablemente llamado ".NET 3.5 Service Pack 1", que se parecía más a una versión principal que a un service pack.

...

A los desarrolladores no les gusta [ADO.NET Entity Framework] debido a la complejidad.

...

a partir de .NET 4.0, LINQ to Entities será la solución de acceso a datos recomendada para LINQ to escenarios relacionales.

Hay una serie de diferencias obvias descritas en ese artículo publicado en @lars, pero la respuesta breve es:

• L2S está estrechamente acoplado: propiedad del objeto al campo específico de la base de datos o, más correctamente, asignación de objetos a un esquema de base de datos específico
• L2S solo funcionará con SQL Server (que yo sepa)
• EF permite asignar una sola clase a varias tablas
• EF manejará relaciones MM
• EF tendrá la capacidad de apuntar a cualquier proveedor de datos ADO.NET

La premisa original era que L2S es para desarrollo rápido y EF para aplicaciones de nivel n más "empresariales", pero eso está vendiendo L2S un poco corto.

LINQ to SQL

1. Fuente de datos homogénea: SQL Server
2. Recomendado para proyectos pequeños solo donde la estructura de datos está bien diseñada
3. La asignación se puede cambiar sin recompilar con SqlMetal.exe
4. .dbml (lenguaje de marcado de base de datos)
5. Mapeo uno a uno entre tablas y clases
6. Apoya la herencia de TPH
7. No soporta tipos complejos
8. Enfoque de almacenamiento primero
9. Vista centrada en la base de datos de una base de datos
10. Creado por el equipo de C #
11. Mejoras admitidas pero no adicionales previstas

Marco de la entidad

1. Fuente de datos heterogéneos: admite muchos proveedores de datos
2. Recomendado para todos los proyectos nuevos excepto:
   • los pequeños (LINQ to SQL)
   • cuando la fuente de datos es un archivo plano (ADO.NET)
3. La asignación se puede cambiar sin recompilar al configurar el modelo y los archivos de asignación Proceso de artefactos de metadatos para copiar en el directorio de salida
4. .edmx (modelo de datos de entidad) que contiene:
   • SSDL (lenguaje de definición de esquema de almacenamiento)
   • CSDL (lenguaje de definición de esquema conceptual)
   • MSL (Lenguaje de especificación de mapeo)
5. Asignaciones uno a uno, uno a muchos, muchos a uno entre tablas y clases
6. Apoya la herencia:
   • TPH (tabla por jerarquía)
   • TPT (tabla por tipo)
   • TPC (tabla por clase de hormigón)
7. Admite tipos complejos
8. Enfoques de código primero, modelo primero, almacenamiento primero
9. Vista centrada en la aplicación de una base de datos
10. Creado por el equipo de SQL Server
11. Futuro de las API de datos de Microsoft

Ver también:

• LINQ To SQL Vs Entity Framework
• Diferencia entre LINQ to SQL y Entity Framework
• Entity Framework vs LINQ TO SQL

Mi experiencia con Entity Framework ha sido menos que estelar. Primero, debe heredar de las clases base EF, así que despídase de los POCO. Su diseño tendrá que estar alrededor del EF. Con LinqtoSQL podría usar mis objetos comerciales existentes. Además, no hay carga diferida, debe implementarlo usted mismo. Existen algunas soluciones para usar POCO y carga diferida, pero existen en mi humilde opinión porque EF aún no está listo. Planeo volver después de 4.0

Encontré una muy buena respuesta aquí que explica cuándo usar qué en palabras simples:

La regla básica para qué marco usar es cómo planificar la edición de sus datos en su capa de presentación.

• Linq-to-Sql : use este marco si planea editar una relación uno a uno de sus datos en su capa de presentación. Lo que significa que no planea combinar datos de más de una tabla en una sola vista o página.

• Entity Framework : use este marco si planea combinar datos de más de una tabla en su vista o página. Para aclarar esto, los términos anteriores son específicos de los datos que serán manipulados en su vista o página, no solo mostrados. Esto es importante de entender.

Con Entity Framework, puede "fusionar" datos de tablas para presentarlos a la capa de presentación en un formulario editable, y luego, cuando se envíe ese formulario, EF sabrá cómo actualizar TODOS los datos de las diversas tablas.

Probablemente haya razones más precisas para elegir EF en lugar de L2S, pero esta sería probablemente la más fácil de entender. L2S no tiene la capacidad de fusionar datos para ver la presentación.

Mi impresión es que su base de datos es bastante enorme o está muy mal diseñada si Linq2Sql no se ajusta a sus necesidades. Tengo alrededor de 10 sitios web más grandes y más pequeños, todos con Linq2Sql. He buscado y Entity Framework muchas veces, pero no puedo encontrar una buena razón para usarlo sobre Linq2Sql. Dicho esto, trato de usar mis bases de datos como modelo, así que ya tengo un mapeo 1 a 1 entre el modelo y la base de datos.

En mi trabajo actual tenemos una base de datos con más de 200 tablas. Una base de datos antigua con muchas soluciones malas para poder ver el beneficio de Entity Framework sobre Linq2Sql, pero aún así preferiría rediseñar la base de datos, ya que la base de datos es el motor de la aplicación y si la base de datos está mal diseñada y es lenta, entonces mi aplicación También será lento. Usar Entity Framework en una base de datos de este tipo parece una solución rápida para disfrazar el modelo malo, pero nunca podría disfrazar el mal rendimiento que obtienes de dicha base de datos.

Puedes encontrar una buena comparación aquí:

http://www.dotnet-tricks.com/Tutorial/entityframework/1M5W300314-Difference-between-LINQ-to-SQL-and-Entity-Framework.html

http://www.c-sharpcorner.com/blogs/entity-framework-vs-linq-to-sql1

Las respuestas aquí han cubierto muchas de las diferencias entre Linq2Sql y EF, pero hay un punto clave al que no se le ha prestado mucha atención: Linq2Sql solo admite SQL Server, mientras que EF tiene proveedores para los siguientes RDBMS:

Proporcionado por Microsoft:

• Controladores ADO.NET para SQL Server, OBDC y OLE DB

A través de proveedores externos:

• MySQL
• Oráculo
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Pájaro de fuego
• Npgsql

para nombrar unos pocos.

Esto hace que EF sea una abstracción de programación poderosa sobre su almacén de datos relacionales, lo que significa que los desarrolladores tienen un modelo de programación consistente para trabajar independientemente del almacén de datos subyacente. Esto podría ser muy útil en situaciones en las que está desarrollando un producto que desea garantizar que interopere con una amplia gama de RDBMS comunes.

Otra situación en la que esa abstracción es útil es cuando usted es parte de un equipo de desarrollo que trabaja con varios clientes diferentes o diferentes unidades de negocios dentro de una organización, y desea mejorar la productividad del desarrollador al reducir la cantidad de RDBMS que deben convertirse. familiarizado con el fin de admitir una gama de diferentes aplicaciones además de diferentes RDBMS.

Descubrí que no podía usar varias bases de datos dentro del mismo modelo de base de datos cuando usaba EF. Pero en linq2sql podría simplemente prefijar los nombres de los esquemas con los nombres de las bases de datos.

Esta fue una de las razones por las que originalmente comencé a trabajar con linq2sql. No sé si EF todavía ha permitido esta funcionalidad, pero recuerdo haber leído que estaba destinada a que no lo permitiera.

Si su base de datos es sencilla y simple, LINQ to SQL funcionará. Si necesita entidades lógicas / abstractas en la parte superior de sus tablas, vaya a Entity Framework.

Ninguno de los dos admite aún los tipos de datos únicos de SQL 2008. La diferencia desde mi perspectiva es que Entity todavía tiene la oportunidad de construir un modelo alrededor de mi tipo de datos geográficos en alguna versión futura, y Linq to SQL, al ser abandonado, nunca lo hará.

Me pregunto qué pasa con nHibernate u OpenAccess ...

Creo que si necesita desarrollar algo rápido sin cosas extrañas en el medio, y necesita la facilidad de tener entidades que representen sus tablas:

Linq2Sql puede ser un buen aliado, usarlo con LinQ desata un excelente momento de desarrollo.

Estoy trabajando para un cliente que tiene un gran proyecto que usa Linq-to-SQL. Cuando comenzó el proyecto, era la opción obvia, porque Entity Framework carecía de algunas características importantes en ese momento y el rendimiento de Linq-to-SQL era mucho mejor.

Ahora EF ha evolucionado y Linq-to-SQL carece de soporte asíncrono, lo cual es ideal para servicios altamente escalables. A veces tenemos más de 100 solicitudes por segundo y, a pesar de que hemos optimizado nuestras bases de datos, la mayoría de las consultas aún demoran varios milisegundos en completarse. Debido a las llamadas a la base de datos síncronas, el hilo está bloqueado y no está disponible para otras solicitudes.

Estamos pensando en cambiar a Entity Framework, únicamente para esta función. Es una pena que Microsoft no haya implementado el soporte asíncrono en Linq-to-SQL (o de código abierto, para que la comunidad pueda hacerlo).

Anexo Diciembre de 2018: Microsoft se está moviendo hacia .NET Core y Linq-2-SQL no es compatible con .NET Core, por lo que debe pasar a EF para asegurarse de que puede migrar a EF.Core en el futuro.

También hay algunas otras opciones a considerar, como LLBLGen . Es una solución ORM madura que existe desde hace mucho tiempo y se ha demostrado que está más preparada para el futuro que las soluciones de datos de MS (ODBC, ADO, ADO.NET, Linq-2-SQL, EF, EF.core).

Linq-to-SQL

Es un proveedor que solo admite SQL Server. Es una tecnología de mapeo para mapear tablas de bases de datos de SQL Server a objetos .NET. Es el primer intento de Microsoft en un ORM: Object-Relational Mapper.

Linq-to-Entities

Es la misma idea, pero usando Entity Framework en segundo plano, como ORM, nuevamente de Microsoft. Es compatible con múltiples bases de datos. La ventaja principal del marco de entidades es que el desarrollador puede trabajar en cualquier base de datos sin necesidad de aprender la sintaxis para realizar cualquier operación en diferentes bases de datos diferentes.

Según mi experiencia personal, Ef es mejor (si no tienes idea sobre SQL) el rendimiento en LINQ es un poco más rápido en comparación con el motivo EF por el lenguaje LINQ escrito en lambda.