Entity Framework vs LINQ to SQL

Ahora que se lanzó .NET v3.5 SP1 (junto con VS2008 SP1), ahora tenemos acceso a .NET entity framework.

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

Según entiendo, el Entity Framework (cuando se usa con LINQ to Entities) es un “hermano mayor” de LINQ to SQL? Si este es el caso, ¿qué ventajas tiene? ¿Qué puede hacer que LINQ to SQL no pueda hacer solo?

LINQ to SQL solo admite el mapeo de 1 a 1 de tablas de base de datos, vistas, sprocs y funciones disponibles en Microsoft SQL Server. Es una gran API para utilizar para la construcción de acceso rápido a 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 un mash-up agregado de objetos que se construyen a partir de una variedad de tablas, fonts, servicios, etc. Se lanzó ADO.Net Framework con .Net Framework 3.5 SP1.

Este es un buen artículo introductorio sobre MSDN: introducción de LINQ a 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 se pondrá en marcha más rápido y entregará más rápido si está trabajando en algo más pequeño.
  • Entity Framework es la manera más completa y sin restricciones de hacerlo. Esto significa que tomará más tiempo por adelantado, se desarrollará más despacio y tendrá más flexibilidad si está trabajando en algo más grande.

¿Está LINQ to SQL 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 un sustituto para ayudarlos a desarrollar LINQ hasta que el ORM real estuviera listo.

La escala de Entity Framework hizo que fallara la fecha límite de .NET 3.5 / Visual Studio 2008. Se completó a tiempo para el desafortunadamente llamado “.NET 3.5 Service Pack 1”, que era más como un lanzamiento importante que un paquete de servicio.

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 a escenarios relacionales.

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

  • L2S está estrechamente vinculado: 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 (hasta donde yo sé)
  • EF permite asignar una sola clase a múltiples tablas
  • EF manejará las relaciones MM
  • EF tendrá la capacidad de apuntar a cualquier proveedor de datos ADO.NET

La premisa original era que L2S es para Rapid Development, y EF para más aplicaciones “empresariales” de n-tier, pero que está vendiendo L2S un poco corto.

LINQ a 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. El mapeo se puede cambiar sin volver a comstackr con SqlMetal.exe
  4. .dbml (Lenguaje de marcado de la base de datos)
  5. Asignación uno a uno entre tablas y clases
  6. Admite la herencia TPH
  7. No admite tipos complejos
  8. Primer enfoque de almacenamiento
  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 posteriores

Marco de la entidad

  1. Fuente de datos heterogénea: admite muchos proveedores de datos
  2. Recomendado para todos los proyectos nuevos, excepto:
    • pequeños (LINQ to SQL)
    • cuando el origen de datos es un archivo plano (ADO.NET)
  3. El mapeo se puede cambiar sin volver a comstackr cuando se configuran los archivos de mapeo y modelo Metadata Artifact Process para copiar en el directorio de salida
  4. .edmx (Modelo de datos de entidad) que contiene:
    • SSDL (lenguaje de definición de esquemas de almacenamiento)
    • CSDL (lenguaje de definición de esquema conceptual)
    • MSL (lenguaje de especificación de mapeo)
  5. Mapeos uno a uno, uno a muchos, muchos a uno entre tablas y clases
  6. Admite heredadera:
    • TPH (tabla por jerarquía)
    • TPT (tabla por tipo)
    • TPC (tabla por clase concreta)
  7. Admite tipos complejos
  8. Enfoque de código, Primer modelo primero, Primer 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
  • Entidad Framework vs LINQ TO SQL

Mi experiencia con Entity Framework ha sido menos que estelar. En primer lugar, debe heredar de las clases base de EF, así que diga adiós a las POCO. Tu diseño tendrá que estar alrededor del EF. Con LinqtoSQL podría usar mis objetos comerciales existentes. Además, no hay carga diferida, tienes que implementarlo tú mismo. Hay algunas soluciones para usar POCO y carga lenta, pero existen en mi humilde opinión porque EF aún no está listo. Planeo regresar después de 4.0

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

La regla básica para saber qué marco usar es cómo planear editar sus datos en su capa de presentación.

  • Linq-To-Sql : use este marco si planea editar una relación de 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 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 se manipularán en su vista o página, no solo se mostrarán. Esto es importante de entender

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

Probablemente haya razones más precisas para elegir EF sobre L2S, pero probablemente sea el más fácil de entender. L2S no tiene la capacidad de combinar datos para la presentación de la vista.

Mi impresión es que su base de datos es muy rica o muy mal diseñada si Linq2Sql no se ajusta a sus necesidades. Tengo alrededor de 10 sitios web, tanto mayores como pequeños, que usan Linq2Sql. He buscado Entity Framework muchas veces, pero no puedo encontrar una buena razón para usarlo en Linq2Sql. Dicho esto, trato de usar mis bases de datos como modelo, por lo que ya tengo una asignación de 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 vieja con muchas soluciones malas, por lo que pude 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 lenta, mi aplicación también será lento El uso del marco Entity en dicha base de datos parece una solución rápida para disfrazar el modelo incorrecto, pero nunca podría ocultar el mal rendimiento que se obtiene de dicha base de datos.

Las respuestas aquí han cubierto muchas de las diferencias entre Linq2Sql y EF, pero hay un punto clave que no ha recibido mucha atención: Linq2Sql solo es compatible con 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
  • Firebird
  • Npgsql

para nombrar unos pocos.

Esto hace que EF sea una poderosa abstracción de progtwigción sobre su almacén de datos relacionales, lo que significa que los desarrolladores tienen un modelo de progtwigció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 asegurar que interopere con una amplia gama de RDBMS comunes.

Otra situación en la que esa abstracción es útil es cuando forma 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 reduciendo la cantidad de RDBMS que tienen que convertirse. familiarizado con el fin de admitir una gama de diferentes aplicaciones además de diferentes RDBMS.

Descubrí que no podía usar múltiples 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 era para que no lo permitiera.

Si su base de datos es simple y directa, LINQ to SQL lo hará. Si necesita entidades lógicas / abstractas sobre sus tablas, vaya a Entity Framework.

Aún no es compatible con los tipos de datos únicos de SQL 2008. La diferencia desde mi punto de vista es que Entity todavía tiene la posibilidad de construir un modelo en torno a mi tipo de datos geográficos en una versión futura, y de Linq a SQL, al ser abandonado, nunca lo hará.

Me pregunto qué pasa con nHibernate, o OpenAccess …

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

Linq2Sql puede ser un buen aliado, usarlo con LinQ da rienda suelta a un gran momento de desarrollo.

Estoy trabajando para clientes que tienen un proyecto grande que usa Linq-to-SQL. Cuando el proyecto comenzó fue 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 mayor.

Ahora EF ha evolucionado y Linq-to-SQL carece de una característica importante para servicios altamente escalables y es compatible con operaciones asincrónicas. Tenemos más de 100 solicitudes por segundo a veces 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 de base de datos sincrónicas, 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 la compatibilidad asincrónica en Linq-to-SQL (o la haya abierto, para que la comunidad pueda hacerlo).

LINQ to SQL y Entity Framework tienen un aspecto similar en la superficie. Ambos proporcionan consulta LINQ en una base de datos utilizando un modelo de datos.

LINQ to SQL evolucionó a partir del proyecto LINQ, que surgió del trabajo en equipo con el desarrollo del lenguaje. Mientras que Entity Framework era un proyecto del equipo de Data Programmability y se centraba en el lenguaje Entity SQL. Microsoft no tiene ninguna intención de privar a LINQ de SQL.

LINQ to SQL sigue siendo parte de ADO.NET mientras que Entity framework tiene una API separada. Entity Framework es la versión superior de LINQ to SQL. El marco de trabajo de Entity Data utiliza el modelo de puente entre su aplicación y su almacén de datos. Es el Modelo de datos de entidad, o EDM, que proporciona la definición de su esquema conceptual, así como la información de esquema de base de datos necesaria para interactuar con la base de datos y, finalmente, un esquema de asignación que vincula a dos.

A continuación se detallan algunas tareas realizadas por Entity Framework (modelo de datos de Entity).

• Genera automáticamente clases del modelo y actualiza esas clases dinámicamente cada vez que cambia el modelo.

• Se ocupa de toda la conectividad de la base de datos para que los desarrolladores no tengan que cargar con la necesidad de escribir muchos códigos para interactuar con la base de datos.

• Proporciona una syntax de consulta común para consultar el modelo, no la base de datos, y luego traduce estas consultas en consultas que la base de datos puede comprender.

• Proporciona un mecanismo para rastrear los cambios en los objetos del modelo a medida que se utilizan en las aplicaciones y maneja las actualizaciones de la base de datos.

Linq-to-SQL

Es proveedor, solo admite SQL Server. Es una tecnología de mapeo para mapear las tablas de la base de datos de SQL Server a objetos .NET. Es el primer bash de Microsoft en un ORM – Object Relational Mapper.

Linq-to-Entities

Es la misma idea, pero utilizando Entity Framework en segundo plano, como ORM – una vez más de Microsoft, es compatible con la ventaja principal de múltiples bases de datos de la entidad. El desarrollador puede trabajar en cualquier base de datos sin necesidad de aprender la syntax para realizar cualquier operación en diferentes bases de datos diferentes.

De acuerdo con mi experiencia personal, Ef es mejor (si no tienes idea sobre SQL), el rendimiento en LINQ es un poco más rápido que el lenguaje LINQ de EF reason escrito en lambda.