Entity Framework VS LINQ a SQL VS ADO.NET ¿con procedimientos almacenados?
¿Cómo calificaría cada uno de ellos en términos de:
- Rendimiento
- Velocidad de desarrollo
- Código limpio, intuitivo y mantenible
- Flexibilidad
- En general
Me gusta mi SQL y así siempre he sido un fan acérrimo de ADO.NET y procedimientos almacenados, pero recientemente tuve un juego con Linq a SQL y me sorprendió lo rápido que estaba escribiendo mi capa de acceso a datos y he decidido pasar algún tiempo realmente entendiendo Linq a SQL o EF... o tampoco?
Solo quiero comprobar, que no hay un gran defecto en cualquiera de estas tecnologías que haría inútil mi tiempo de investigación. Por ejemplo, el rendimiento es terrible, es genial para aplicaciones simples, pero solo puede llevarte hasta cierto punto.
Actualización: Puede concentrarse en EF VS L2S VS SPS en lugar de OR VS SPs. Estoy principalmente interesado por EF VS L2S, pero estoy dispuesto a compararlos con procs almacenados también, ya que el SQl simple es algo de lo que sé mucho.
4 answers
En primer lugar, si está comenzando un nuevo proyecto, vaya con Entity Framework ("EF") - ahora genera mucho mejor SQL (más como lo hace Linq to SQL) y es más fácil de mantener y más potente que Linq to SQL ("L2S"). A partir del lanzamiento de.NET 4.0, considero que Linq to SQL es una tecnología obsoleta. MS ha sido muy abierta acerca de no continuar el desarrollo de L2S más.
1) Rendimiento
Esto es difícil de responder. Para la mayoría de las operaciones de una sola entidad (CRUD ) encontrará un rendimiento casi equivalente con las tres tecnologías. Tienes que saber cómo funcionan EF y Linq to SQL para usarlos al máximo. Para operaciones de gran volumen como consultas de sondeo, es posible que desee que EF / L2S "compile" su consulta de entidad de modo que el marco no tenga que regenerar constantemente el SQL, o puede tener problemas de escalabilidad. (ver ediciones)
Para actualizaciones masivas donde está actualizando cantidades masivas de datos, SQL sin procesar o una el procedimiento siempre funcionará mejor que una solución OR porque no tiene que ordenar los datos a través del cable al OR para realizar actualizaciones.
2) Velocidad de desarrollo
En la mayoría de los escenarios, EF eliminará los procesos SQL/almacenados desnudos cuando se trata de velocidad de desarrollo. EF designer puede actualizar su modelo desde su base de datos a medida que cambia (previa solicitud), para que no tenga problemas de sincronización entre su código objeto y su código de base de datos. El único el tiempo que no consideraría usar un OR es cuando está haciendo una aplicación de tipo informe/panel donde no está haciendo ninguna actualización, o cuando está creando una aplicación solo para realizar operaciones de mantenimiento de datos sin procesar en una base de datos.
3) Código limpio / Mantenible
Sin duda, EF supera a SQL/sprocs. Debido a que sus relaciones son modeladas, las uniones en su código son relativamente poco frecuentes. Las relaciones de las entidades son casi evidentes para el lector para la mayoría consulta. Nada es peor que tener que ir de nivel a nivel de depuración o a través de múltiples SQL/nivel medio para comprender lo que realmente está sucediendo con sus datos. EF trae su modelo de datos a su código de una manera muy poderosa.
4) Flexibilidad
Los procs almacenados y SQL raw son más "flexibles". Puede aprovechar sprocs y SQL para generar consultas más rápidas para el caso específico impar, y puede aprovechar la funcionalidad de base de datos nativa más fácil de lo que puede con y OR.
5) Global
No se deje atrapar por la falsa dicotomía de elegir un OR vs el uso de procedimientos almacenados. Puede usar ambos en la misma aplicación, y probablemente debería hacerlo. Las operaciones grandes a granel deben ir en procedimientos almacenados o SQL (que en realidad puede ser llamado por el EF), y EF debe ser utilizado para sus operaciones CRUD y la mayoría de las necesidades de su nivel medio. Tal vez usted elegiría usar SQL para escribir sus informes. Supongo que la moraleja de la historia es lo mismo de siempre. Utilice la herramienta adecuada para el trabajo. Pero lo más delgado es que EF es muy bueno hoy en día (a partir de.NET 4.0). Pasa algo de tiempo real leyendo y entendiéndolo en profundidad y puedes crear algunas aplicaciones increíbles y de alto rendimiento con facilidad.
EDIT : EF 5 simplifica un poco esta parte con consultas LINQ autocompiladas , pero para cosas reales de alto volumen, definitivamente necesitarás probar y analizar lo que mejor se adapte a ti en el mundo real.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2018-07-31 17:46:56
Procedimientos Almacenados:
(++)
- Gran flexibilidad
- Control total sobre SQL
- El rendimiento más alto disponible
(--)
- Requiere conocimiento de SQL
- Los procedimientos almacenados están fuera del control de código fuente
- Cantidad sustancial de "repetirse" mientras se especifican los mismos nombres de tabla y campo. La alta probabilidad de romper la aplicación después de cambiar el nombre de una entidad de base de datos y perder algunas referencias a ella en alguna parte.
- Desarrollo lento
ORM:
(+)
- Desarrollo rápido
- Código de acceso a datos ahora bajo control de fuente
- Estás aislado de los cambios en DB. Si eso sucede, solo necesita actualizar su modelo / asignaciones en un solo lugar.
(-)
- El rendimiento puede ser peor
- Poco o ningún control sobre SQL produce el SQL (podría ser ineficiente o peor buggy). Podría tener que intervenir y reemplazarlo con procedimientos almacenados personalizados. Eso hará que su código sea desordenado (algunos LINQ en código, algunos SQL en código y/o en la base de datos fuera del control de código fuente).
- Como cualquier abstracción puede producir desarrolladores de" alto nivel " que no tienen idea de cómo funciona bajo el capó
La compensación general es entre tener una gran flexibilidad y perder mucho tiempo frente a estar restringido en lo que puede hacer pero hacerlo muy rápidamente.
No hay una respuesta general a esta pregunta. Es una cuestión de guerras santas. También depende de un proyecto en la mano y sus necesidades. Elige lo que funciona mejor para ti.
Su pregunta es básicamente O / RM vs escritura a mano SQL
Echa un vistazo a algunas de las otras soluciones de O/RM por ahí, L2S no es el único (NHibernate, ActiveRecord)
Http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software
Para abordar las preguntas específicas:
- Depende de la calidad de la solución O / RM, L2S es bastante bueno para generar SQL
- Esto es normalmente mucho más rápido usando un O / RM una vez que grok el proceso
- El código también suele ser mucho más ordenado y más fácil de mantener
- Straight SQL, por supuesto, le dará más flexibilidad, pero la mayoría de O/RM pueden hacer todo menos las consultas más complicadas
- En general, sugeriría ir con una O/RM, la pérdida de flexibilidad es negligible
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:26:32
LINQ-to-SQL es una notable pieza de tecnología que es muy simple de usar, y en general genera muy buenas consultas al back-end. LINQ-to-EF fue programado para suplantarlo, pero históricamente ha sido extremadamente torpe de usar y generado SQL muy inferior. No conozco el estado actual de las cosas, pero Microsoft prometió migrar toda la bondad de L2S en L2EF, así que tal vez todo está mejor ahora.
Personalmente, tengo una aversión apasionada de las herramientas OR (ver mi diatriba aquí para los detalles), por lo que no veo ninguna razón para favorecer L2EF, ya que L2S me da todo lo que espero necesitar de una capa de acceso a datos. De hecho, incluso creo que las características de L2S, como las asignaciones hechas a mano y el modelado de herencia, agregan una complejidad completamente innecesaria. Pero sólo soy yo. ;-)
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:10:44