¿Cómo es .net Entity Framework overkill versus LinqToSql?

Question

He oído decir que Entity Framework es excesivo o que es difícil de aprender en comparación con LinqToSql.

Me pregunto de qué manera? Usé LinqToSql y me gusta. Entonces, estoy probando el EF y por las cosas que estoy haciendo, parecen casi exactamente iguales. Los espacios de nombre y los nombres de los métodos son diferentes, pero hasta ahora no veo nada que haga que EF sea más difícil que LinqToSql.

Estoy seguro de que si empiezo a hacer más cosas de compilación se vuelve más complejo. Pero, de nuevo, probablemente no pueda hacer lo mismo con LinqToSql en absoluto, así que lo veo como un plus para el EF en caso de que quiera hacer algo más complejo.

¿EF usa más recursos que LinqToSql tanto que no debería usarlo si todo lo que necesito es la funcionalidad LinqToSql?

Actualización: Hice algunas pruebas y mis pruebas parecen apuntar a Linq a las entidades que funcionan mejor que Linq a SQL.

Primero eliminé 1000 registros de una sola tabla, agregué 1000 registros, edité 1000 registros y luego los relacioné con un DataView. LinqToSQL: 5 segundos LinqToEntities: 2 segundos

Realicé la misma prueba utilizando dos tablas unidas y los resultados fueron similares.

Mis pruebas parecen apoyar otro post: Linq To Sql vs Entity Framework Performance

Actualización 2:

Gracias por las respuestas. Me parece que Linq to Entities no es realmente excesivo contra Linq to SQL. Después de investigar más, creo que ir con Linq to Entities es el camino a seguir. Parece tener un mejor rendimiento.

Creo que las declaraciones de "exceso" que he escuchado se hacen porque Linq to Entities puede hacer mucho más que Linq To SQL y requiere más configuración (aproximadamente 1 línea más en el web.config). También hay cosas pequeñas que Linq to Entities hace diferente de Linq a SQL que pueden hacer que alguien sienta que Linq to Entities es más complicado. Pero una vez que aprendes cómo hacer las cosas, parece que Linq to Entities no es más complicado que Linq to SQL.

Answer 1

Mi respuesta: Haga una simple comparación del tiempo necesario para realizar una secuencia simple de Obtener/Editar/Actualizar. Creo que encontrará que LINQ to SQL es dos veces más rápido. Hice un proyecto de comparación rápido cuando estaba investigando las diferencias.
Los resultados donde: Entity Framework 8.700 milisegundos LINQ a SQL 3.100 milisegundos conjuntos de datos de 2.000 milisegundos

Así que para mí era una cuestión sencilla. Usa DataSets o usa Linq-Sql. ¡Entity Framework ni siquiera tuvo en cuenta!

link text

Answer 2

Corrígeme si me equivoco, pero el marco de la entidad sólo debe entrar en juego cuando se necesita para transformar los objetos de back-end, como cuando estás combinando tablas de distintas fuentes de datos, la división tablas, etc. Agrega la capa de entidad para que pueda ocultar todas las tuberías y simplemente tratar con sus entidades limpias. Si solo lo usa 1 contra 1 en sus tablas como lo haría en LINQ to SQL, entonces estoy seguro de que la capa de complejidad que no está utilizando disminuirá la velocidad. Parece que LINQ to SQL es la herramienta adecuada para el trabajo correcto en su caso hasta que tenga necesidades de fuente de datos más complejas.

Answer 3

Antes de sumergirse en Linq a SQL, consulte this article por su administrador de programa. Él plantea una pregunta directa "¿LINQ to SQL Dead?" La respuesta no es tan simple. Definitivamente no es "no". Me parece más a "probablemente sea".

Sugeriría antes de sumergirse en EF (ahora llamado Linq To Entities) considerar seriamente NHibernate, pero ese es mi sesgo personal.

Answer 4

Linq to SQL y Entity Framework son bestias conceptualmente diferentes y debe elegir según cómo se ajusten a sus necesidades en lugar de microbenchmarks. Incluso si Entity Framework fue más lento, es el enfoque del equipo de ADO.NET en Microsoft y se mejorará muchas veces. Linq-to-SQL está efectivamente congelado.

Conceptualmente son diferentes en que Linq-to-SQL es solo una forma de realizar consultas de bases de datos utilizando Linq. Suena bastante obvio, pero el punto es: estás accediendo a los datos, estructurados según el modelo de base de datos de la misma. Aunque los FK se transforman adecuadamente, aún tiene objetos en exceso donde los datos se normalizaron en tablas diferentes. Cada consulta que escribes tiene que lidiar con ese tipo de cosas.

Entity Framework le permite construir declarativamente una capa que represente sus datos de la manera que debería ser representada en la memoria, trayendo datos de múltiples tablas en un solo objeto donde corresponda; representando relaciones de muchos a muchos como propiedades de colección, etc. Y las consultas que escriba serán para este modelo y serán mucho más claras y obvias en su propósito (¡no más de 15 combinaciones de tablas!).

O'Reilly tiene un amplio libro que sale de Entity Framework el 15 de enero de 2009 (vista previa disponible ahora en Roughcuts) si no está seguro sobre el uso de Entity Framework: la documentación de MSDN es muy mala en este momento, lo que hace proponiéndolo aún más difícil. Creo que vale la pena usarlo a largo plazo para todos los proyectos menos triviales (y personalmente, si estuviera escribiendo algo trivial, simplemente usaría ADO.NET2 directamente y me olvidaría de Linq).

Answer 5

Tenga cuidado, LinqToEntities puede hacer cosas realmente interesantes si utiliza consultas con, por ejemplo, group by. Nunca logré que LinqToEntities transformara un grupo en un grupo SQL real, sino que genera bloques de código masivos que pueden ser realmente ineficaces.

Por ejemplo, revisa el siguiente enlace: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

Si intenta escribir consultas "no triviales", ObjectQuery.ToTraceString() es su mejor amigo para asegurarse de que EF no hace algo realmente estúpido a tus espaldas.

Answer 6

¿Por qué no hacer simplemente una consulta SQL ordinaria con SqlDataReader y vincularlos a una lista genérica. Parece que SQL es mucho más flexible y poderoso que cualquier ORM. En la práctica de todos modos !! ¿SQL está muerto? Y ese debe ser el enfoque más rápido, y la desventaja son las cadenas sql, pero usted está trabajando más cerca del metal y siente que tiene mucho más control que con cualquier ORM. Se siente como ORM: s siempre tiene algún error y hace que las consultas más complejas sean un dolor en el culo y lleva mucho más tiempo escribir que si las hiciera en SQL simple. ¿O soy solo yo que soy algo nuevo en ORM: s?