¿Cómo es.net Entity Framework overkill versus LinqToSql?
linq-to-sql entity-framework (6)
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.
¿El 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 Entidades que funcionan mejor que Linq a SQL.
Primero borro 1000 registros de una sola tabla, agrego 1000 registros, edito 1000 registros y luego los relaciono con DataView. LinqToSQL: 5 segundos LinqToEntities: 2 segundos
Realicé la misma prueba usando dos tablas unidas y los resultados fueron similares.
Mis pruebas parecen ser compatibles con otra publicación: 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.
Mi respuesta: haga una comparación simple 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 fueron: Marco de la entidad 8.700 milisegundos LINQ a SQL 3.100 milisegundos Conjuntos de datos 2.000 milisegundos
Entonces para mí fue una pregunta simple. Usa DataSets o usa Linq-Sql. ¡Entity Framework ni siquiera tuvo en cuenta!
Antes de sumergirse en Linq To SQL, consulte este artículo 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 prejuicio personal.
Corrígeme si me equivoco, pero el marco de entidad solo debe entrar en juego cuando necesites transformar los objetos de fondo, como cuando estás combinando tablas de diferentes fuentes de datos, dividiendo tablas, etc. Añade 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.
Linq to SQL y Entity Framework son bestias conceptualmente diferentes y usted debe hacer su elección en función de cómo se ajusten a sus necesidades en lugar de en 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 forma en 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 bastante desagradable en este momento, lo que hace que proponerla sea 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).
Sin embargo, ten cuidado, LinqToEntities puede hacer cosas realmente interesantes si usas 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, consulte el siguiente enlace: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68
Si intentas escribir consultas "no triviales", ObjectQuery.ToTraceString () es tu mejor amigo para asegurarte de que EF no haga algo realmente estúpido a tus espaldas.
¿Por qué no hacer 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 lo hiciera en SQL simple. ¿O soy solo yo que soy algo nuevo en ORM: s?