Entity Framework vs LINQ a SQL

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 usted está trabajando en algo más pequeño.
• Entity Framework es la forma completa y sin restricciones de hacerlo. Esto significa que tomará más tiempo por adelantado, se desarrollará más lento 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 un sustituto para ayudarlos a desarrollar LINQ hasta que el OR real estuviera listo.

...

La escala de Entity Framework hizo que no se cumpliera 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 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 escenarios relacionales de LINQ to.

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

• L2S es una propiedad de objeto estrechamente acoplada a un campo específico de la base de datos o más correctamente la 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á las relaciones M-M
• EF tendrá la capacidad de dirigirse a cualquier ADO.NET datos proveedor

La premisa original era que L2S es para un Desarrollo Rápido, y EF para aplicaciones n-tier más "emprendedoras", pero eso es vender 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. 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. Soporta TPH herencia
7. No soporta tipos complejos
8. Almacenamiento-primera aproximación
9. Vista centrada en la base de datos de un base de datos
10. Creado por C # team
11. Apoyado pero no otras mejoras previstas

Entity Framework

1. Heterogeneus datasource: Soporta muchos proveedores de datos
2. Recomendado para todos los nuevos proyectos excepto:
   • pequeños (LINQ a SQL)
   • cuando la fuente de datos es un archivo plano (ADO.NET)
3. La asignación se puede cambiar sin recompilar al configurar el proceso de Artefacto de metadatos de archivos de modelo y asignación para Copiar Directorio de salida
4. .edmx (Entity Data Model) que contiene:
   • SSDL (Lenguaje de Definición de Esquema de Almacenamiento)
   • CSDL (Conceptual Schema Definition Language)
   • MSL (Lenguaje de Especificación de Mapeo)
5. Mapeos uno a uno, uno a muchos, muchos a uno entre tablas y clases
6. Soporta herencia:
   • TPH (Tabla Por Jerarquía)
   • TPT (Tabla Por Tipo)
   • TPC (Tabla Por Clase De Hormigón)
7. Soporta tipos complejos
8. Enfoques primero en el código, primero en el modelo, primero en el almacenamiento
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

Véase también:

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

Mi experiencia con Entity Framework ha sido menos que estelar. Primero, tienes que heredar de las clases base EF, así que di adiós a POCOs. Su diseño tendrá que estar alrededor de la EF. Con LinqToSql podría usar mis objetos de negocio existentes. Además, no hay carga perezosa, tienes que implementarlo tú mismo. Hay algunas soluciones para usar POCOs y lazy loading, pero existen en mi humilde opinión porque EF aún no está listo. Planeo volver a él 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é framework usar es cómo planificar edición de los datos en la capa de presentación.

• Linq-To-Sql - use este framework si planea editar un uno-a-uno relación de los datos en la capa de presentación. Es decir, tú no planee combinar datos de más de una tabla en una vista o page.

• Entity Framework - use este framework si planea combinar datos de más de una tabla en tu vista o página. Hacer este más claro, los términos anteriores son específicos para los datos que serán manipulado en tu vista o página, no solo mostrado. Esto es es importante entenderlo.

Con Entity Framework puede "fusionar" los datos presentados juntos para presentar a la capa de presentación en una forma editable, y luego cuando se envía el formulario, EF sabrá cómo actualizar TODOS los datos de las diversas mesas.

Probablemente hay razones más precisas para elegir EF sobre L2S, pero esta sería probablemente la más fácil de entender. L2S no tener la capacidad de combinar 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 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, 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 antigua base de datos con muchas soluciones malas, así que allí 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, entonces mi aplicación también será lenta. El uso de Entity framework en una base de datos parece un quickfix para disfrazar el mal modelo, pero nunca podría disfrazar el mal rendimiento de una 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:

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

A través de terceros proveedores:

• MySQL
• Oracle
• DB2
• VistaDB
• SQLite
• PostgreSQL
• Informix
• U2
• Sybase
• Synergex
• Firebird
• Npgsql

Por nombrar algunos.

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 consistente con el que trabajar independientemente del almacén de datos subyacente. Esto podría ser muy útil en situaciones donde está desarrollando un producto que desea garantizar que interoperará 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 negocio dentro de una organización, y desea mejorar la productividad del desarrollador reduciendo el número de RDBMS con los que deben familiarizarse para admitir una gama de aplicaciones diferentes 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 esquema con nombres de base de datos.

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

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

Ninguno de los dos soporta los tipos de datos únicos 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, o OpenAccess...

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

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

Estoy trabajando para un cliente que tiene un gran proyecto que está usando Linq to SQL. Cuando el proyecto comenzó fue la elección obvia, porque Entity Framework carecía de algunas características importantes en ese momento y el rendimiento de Linq-to-SQL era mucho más btter.

Ahora EF ha evolucionado y Linq-to-SQL carece de una característica importante para servicios altamente escalables y que es el soporte para 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 todavía toma varios milisegundos para completar. Debido a las llamadas sincrónicas a la base de datos, el subproceso está bloqueado y no está disponible para otras solicitudes.

Estamos pensando en cambiar a Entity Framework, únicamente para esta característica. Es una pena que Microsoft no implementara soporte asincrónico en Linq-to-SQL (o de código abierto, por lo que la comunidad podría hacerlo).

LINQ a SQL y Entity Framework parecen similares en la superficie. Ambos proporcionan Consulta LINQ contra una base de datos usando un modelo de datos.

LINQ a SQL evolucionó del proyecto LINQ, que surgió del trabajo en equipo con desarrollo del lenguaje.Mientras que El Entity Framework fue un proyecto del equipo de Programabilidad de datos y se centró en el lenguaje SQL de la Entidad. Microsoft no tiene ninguna intención de degradar LINQ a SQL.

LINQ a SQL sigue siendo la parte de ADO.NET mientras que la Entidad framework tiene API separada. Entity framework es la versión superior de LINQ a SQL.Entity framework utiliza Entity Data Model para crear puentes 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 del esquema de base de datos necesaria para interactuar con la base de datos y, finalmente, un esquema de asignación que se vincula a dos.

Aquí hay algunas tareas realizadas por Entity Framework(Entity data modelo).

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

• Se encarga de toda la conectividad de la base de datos para que los desarrolladores no se vean agobiados por tener 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 puede entender.

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

Linq-to-SQL

Es un proveedor que solo admite SQL Server. Es una tecnología de asignación para asignar tablas de bases de datos de SQL Server a objetos. NET. Es el primer intento de Microsoft en un Mapeador Rel-Object-Relational.

Linq-to-Entities

Es la misma idea, pero el uso de Entity Framework en segundo plano, como el OR - de nuevo de Microsoft, Que soporta múltiples bases de datos principal ventaja de entity framework es desarrollador puede trabajar en cualquier base de datos no hay necesidad de aprender sintaxis para realizar cualquier operación en diferentes bases de datos

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