Entity Framework frente a LINQ a SQL

StackOverflow https://stackoverflow.com/questions/8676

Pregunta

Ahora que se lanzó .NET v3.5 SP1 (junto con VS2008 SP1), ahora tenemos acceso al marco de entidades .NET.

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

Según tengo entendido, 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 por sí solo?

¿Fue útil?

Solución

LINQ to SQL solo admite la asignación 1 a 1 de tablas de bases de datos, vistas, sprocs y funciones disponibles en Microsoft SQL Server.Es una excelente API para usar en 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 varios proveedores de bases de datos, servidores de aplicaciones o protocolos diferentes 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 se lanzó con .Net Framework 3.5 SP1.

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

Otros consejos

Creo que la respuesta rápida y sucia es que

  • LINQ to SQL es la forma rápida y sencilla 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 y sin restricciones de hacerlo.Esto significa que tomará más tiempo desde el principio, 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 a SQL] como algo que "nunca se suponía que existiera". Esencialmente, se suponía que era sustituto para ayudarlos a desarrollar LINQ hasta que el Real Orm estuviera listo.

...

La escala de Entity Framework hizo que no cumpliera con 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 parecía más una versión importante que un service pack.

...

A los desarrolladores no les gusta [ADO.NET Entity Framework] debido a su 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 el artículo que publicó @lars, pero la respuesta breve es:

  • L2S está estrechamente acoplado: propiedad del objeto a un campo específico de la base de datos o, más correctamente, mapeo 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 varias tablas
  • EF manejará las relaciones M-M
  • EF tendrá la capacidad de apuntar a cualquier proveedor de datos ADO.NET

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

LINQ a SQL

  1. Fuente de datos homogénea:servidor SQL
  2. Recomendado solo para proyectos pequeños donde la estructura de datos está bien diseñada.
  3. La asignación se puede cambiar sin volver a compilar con SqlMetal.exe
  4. .dbml (lenguaje de marcado de base de datos)
  5. Mapeo uno a uno entre tablas y clases.
  6. Soportes TPH herencia
  7. No admite 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. Compatible pero no se pretenden realizar más mejoras

Marco de la entidad

  1. Fuente de datos heterogénea: Admite muchos proveedores de datos
  2. Recomendado para todos los proyectos nuevos excepto:
    • los pequeños (LINQ a SQL)
    • cuando la fuente de datos es un archivo plano (ADO.NET)
  3. La asignación se puede cambiar sin volver a compilar al configurar archivos de modelo y asignación Proceso de artefacto de metadatos para copiar al 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 esquemas conceptuales)
    • MSL (lenguaje de especificación de mapeo)
  5. Asignaciones uno a uno, uno a muchos, muchos a uno entre tablas y clases
  6. Admite herencia:
    • TPH (tabla por jerarquía)
    • TPT (Tabla por tipo)
    • TPC (Tabla por clase de hormigón)
  7. Admite tipos complejos
  8. Enfoques que priorizan el código, el modelo y el almacenamiento
  9. Vista centrada en la aplicación de una base de datos
  10. Creado por el equipo de SQL Server
  11. El futuro de las API de datos de Microsoft

Ver también:

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

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

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

  • Linq a 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 cualquier visión o página.

  • Marco de la entidad - 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 para entender.

Con el marco de la entidad, puede "fusionar" los datos presentados para presentarse a la capa de presentación en forma editable, y luego, cuando se envíe ese formulario, EF sabrá cómo actualizar todos los datos de las diversas tablas.

Probablemente hay razones más precisas para elegir EF sobre L2s, pero esta probablemente sería la más fácil de entender.L2S no tiene la capacidad de fusionar datos para la presentación de la vista.

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, tanto más grandes como más pequeños, todos usando 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 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, 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 es lenta, entonces mi aplicación también será lento.El uso de Entity Framework en una base de datos de este tipo 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 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
  • informax
  • U2
  • Sybase
  • Sinergia
  • pájaro de fuego
  • npgsql

para nombrar unos pocos.

Esto convierte a EF en una poderosa abstracción de programación sobre su almacén de datos relacional, lo que significa que los desarrolladores tienen un modelo de programación coherente con el que trabajar independientemente del almacén de datos subyacente.Esto podría resultar muy útil en situaciones en las que esté desarrollando un producto que desee garantizar que interoperará 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 de los desarrolladores reduciendo la cantidad de RDBMS en los que deben convertirse. familiarizado con el fin de admitir una variedad de aplicaciones diferentes 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 anteponer los nombres de los esquemas con los nombres de las bases de datos.

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

Si su base de datos es directa y sencilla, LINQ to SQL será suficiente.Si necesita entidades lógicas/abstraídas encima de sus tablas, elija Entity Framework.

Ninguno de los dos admite todavía 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 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 desata un gran ritmo de desarrollo.

Estoy trabajando para un cliente que tiene un gran proyecto que utiliza Linq-to-SQL.Cuando comenzó el proyecto, era la elección obvia, porque a Entity Framework le faltaban 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 excelente 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 todavía tardan varios milisegundos en completarse.Debido a las llamadas sincrónicas a la base de datos, 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 soporte asíncrono en Linq-to-SQL (o no lo haya abierto, para que la comunidad pueda hacerlo).

Anexo de 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 poder migrar a EF.Core en el futuro.

También hay 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 y Entity Framework parecen similares en la superficie.Ambos proporcionan consultas LINQ en una base de datos utilizando un modelo de datos.

Linq a SQL evolucionó desde el proyecto LINQ, que salió del equipo trabajando con el desarrollo del lenguaje. Mientras que el marco de la entidad era un proyecto del equipo de programabilidad de datos y se centró en el lenguaje SQL de la entidad.Microsoft realmente no tiene intención de desvalorizar LINQ to 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.Entity framework utiliza Entity Data Model para establecer un puente entre su aplicación y su almacén de datos.Es el Entity Data Model, o EDM, el que proporciona la definición de su esquema conceptual, así como la información del esquema de la base de datos necesaria para interactuar con la base de datos y, finalmente, un esquema de mapeo que se vincula a dos.

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

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

• Se encarga de toda la conectividad de la base de datos para que los desarrolladores no tengan que escribir mucho código para interactuar con la base de datos.

• Proporciona una sintaxis 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 pueda entender.

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

Linq a 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 con un ORM (Object-Relational Mapper).

Linq a entidades

Es la misma idea, pero usando Entity Framework en segundo plano, como ORM, nuevamente de Microsoft. La principal ventaja de Entity Framework es que admite múltiples bases de datos. 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.

De acuerdo con mi experiencia personal, EF es mejor (si no tiene idea de SQL) El rendimiento en LINQ es un poco más rápido, ya que compare con la razón EF Linq Language escrito en Lambda.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top