Entity Framework VS LINQ to SQL VS ADO.NET con procedimientos almacenados? [cerrado]

430

¿Cómo calificaría cada uno de ellos en términos de:

Actuación
Velocidad de desarrollo
Código ordenado, intuitivo y mantenible
Flexibilidad
En general

Me gusta mi SQL y siempre he sido un fanático de ADO.NET y de los procedimientos almacenados, pero recientemente tuve una jugada con Linq to SQL y me impresionó la rapidez con que escribía mi capa DataAccess y decidí gastar ¿Alguna vez entendiste realmente Linq to SQL o EF ... o ninguno?

Solo quiero comprobar que no hay un gran defecto en ninguna de estas tecnologías que pueda inutilizar mi tiempo de investigación. Por ejemplo, el rendimiento es terrible, es genial para aplicaciones simples, pero solo puede llevarte lejos.

Actualización: ¿Puede concentrarse en EF VS L2S VS SP en lugar de ORM VS SP? Estoy interesado principalmente en EF VS L2S. Pero también estoy ansioso por compararlos con los procesos almacenados, ya que SQl es algo de lo que sé mucho.

— Desarrollador Británico
fuente

94

no es constructivo y, sin embargo, ¿hay tantos votos positivos? ...;)

— BritishDeveloper

34

No veo por qué alguien marcó esto como no constructivo. Me parece realmente bueno. +1 de mi parte

— Thanushka

10

Esta es una excelente pregunta en mi opinión. Personalmente, he notado que Entity Framework y todos los ORM similares son más lentos en comparación con el código ADO.Net simple / simple. Hice esta prueba hace 2 años y luego nuevamente una semana atrás. No estoy seguro de cómo LINQ to SQL se compara con EF. Pero ADO.Net siempre será el mejor en rendimiento. Si desea ahorrar tiempo de desarrollo, Entity Framework es una buena herramienta, pero definitivamente no cuando el rendimiento es su principal preocupación.

— Sunil

2

@Timeless: existe una tendencia a no confiar en los mecanismos de la base de datos. Cada motor de base de datos tiene su propio lenguaje de procedimiento almacenado, por lo que hay aprendizaje adicional. El 99.9% de los desarrolladores pueden confiar en los ORM, que producen un código bastante bueno y crean SQL automáticamente. La diferencia de rendimiento es marginal en caso de CRUD simple. Los procedimientos almacenados son más difíciles de desarrollar y mantener. Hace unos años, cuando no había ORM y nada se generaba mágica y automáticamente de la base de datos. Se consideró que escribir SP no tomaba tanto tiempo, ya que era una alternativa a escribir sentencias SQL en la aplicación.

— LukLed

44

@Sunil es correcto, aunque no lo suficientemente prolijo. El problema es que todos piensan que su principal preocupación es el rendimiento de la aplicación. Cuando hablo de aplicaciones que requieren un rendimiento superior, pienso en transacciones de bases de datos de alto volumen de C ++ MMO o de gran volumen para clientes en los millones. Realmente debe centrarse en los principios orientados a objetos como la mantenibilidad , la legibilidad , la ignorancia de persistencia y la separación de la lógica de dominio . Especialmente cuando el aumento del rendimiento es menor en el mejor de los casos o inexistente en muchos casos.

— Suamere

430

En primer lugar, si está comenzando un nuevo proyecto, vaya con Entity Framework ("EF"): ahora genera un SQL mucho mejor (más parecido a 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 abierto sobre no continuar con el desarrollo de L2S.

1) rendimiento

Esto es difícil de responder. Para la mayoría de las operaciones de una sola entidad ( CRUD ), encontrará casi un rendimiento 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 alto 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 encontrarse con problemas de escalabilidad. (ver ediciones)

Para las actualizaciones masivas donde está actualizando cantidades masivas de datos, el SQL sin procesar o un procedimiento almacenado siempre funcionará mejor que una solución ORM porque no tiene que reunir los datos a través del cable al ORM 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 la velocidad de desarrollo. El diseñador de EF 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 de objeto y el código de su base de datos. El único momento en el que no consideraría usar un ORM es cuando está haciendo una aplicación de tipo informe / panel de control donde no está realizando 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 ordenado / mantenible

Sin dudas, EF supera a SQL / sprocs. Debido a que sus relaciones están 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 de las consultas. Nada es peor que tener que pasar de una depuración de nivel a nivel 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 procesos almacenados y el SQL sin procesar son más "flexibles". Puede aprovechar sprocs y SQL para generar consultas más rápidas para un caso específico extraño, y puede aprovechar la funcionalidad de base de datos nativa más fácilmente que con ORM.

5) general

No se deje atrapar por la falsa dicotomía de elegir un ORM versus usar procedimientos almacenados. Puede usar ambos en la misma aplicación, y probablemente debería hacerlo. Las grandes operaciones masivas deben ir en procedimientos almacenados o SQL (que en realidad puede ser llamado por el EF), y EF debe usarse para sus operaciones CRUD y la mayoría de las necesidades de su nivel medio. Quizás elija usar SQL para escribir sus informes. Supongo que la moraleja de la historia es la misma de siempre. Use la herramienta adecuada para el trabajo. Pero lo flaco es que EF es muy bueno hoy en día (a partir de .NET 4.0). Dedique un poco de tiempo real a leerlo y comprenderlo en profundidad y puede crear algunas aplicaciones increíbles de alto rendimiento con facilidad.

EDITAR : EF 5 simplifica un poco esta parte con las consultas LINQ compiladas automáticamente , pero para cosas de alto volumen real, definitivamente necesitará probar y analizar qué le queda mejor en el mundo real.

— Dave Markle
fuente

35

Absolutamente brillante respuesta. De hecho, ahora estoy usando EF para desarrollar rápidamente una aplicación. Si el rendimiento se convierte en un problema, los procesos almacenados se incorporarán para refactorizar las consultas EF de mal desempeño. ¡Gracias!

— BritishDeveloper

17

@BritishDeveloper: Además, no olvides el poder de usar las vistas también. Hemos tenido un gran éxito al definir un par de puntos de vista en nuestros proyectos L2S y aprovecharlos donde el marco parece escribir consultas pobres. De esa manera, obtenemos todos los beneficios de usar el marco con todos los beneficios de escribir nuestro propio SQL.

— Dave Markle

55

También estoy usando Vistas;) Más como una solución alternativa para la limitación de db no cruzada de EF. Sin embargo, es una buena idea para la optimización. Gracias

— BritishDeveloper

55

Definitivamente una gran respuesta. Solo quería agregar una observación que tuve en mi propia experiencia con L2S vs EF4. Cambié de L2S -> EF4 después de que nos dimos cuenta de que podríamos estar usando varios RDMBS denetnet ... pero, mientras seguía ejecutando MSSQL, la caída del rendimiento se mostró principalmente en el área GUI de mi aplicación. El enlace de datos al conjunto de resultados en L2S fue mucho más rápido que EF4. Es exactamente la misma consulta en la misma base de datos. Sin embargo, una cosa a tener en cuenta aquí es que estoy devolviendo 90k + registros, por lo que la diferencia fue bastante obvia. ¿Quizás en series más pequeñas no es un problema? No estoy seguro de cómo iba a escala aunque con sitios de alto vol ...

— bbqchickenrobot

55

Buena respuesta Acabo de pasar 4 semanas trabajando con LINQ-to-Entities, intentando calzar todo en él, antes de darme cuenta finalmente de que necesita SQL nativo para cosas como copia masiva, eliminación masiva, eliminación ultrarrápida de duplicados de una base de datos, etc. Use el herramienta adecuada para el trabajo, no hay vergüenza en mezclar SQL nativo con el marco LINQ to Entities.

— Contango

93

Procedimientos almacenados:

(+)

Gran flexibilidad
Control total sobre SQL
El mayor rendimiento disponible.

(-)

Requiere conocimiento de SQL
Los procedimientos almacenados están fuera del control de la fuente.
Cantidad sustancial de "repetirse" mientras se especifican los mismos nombres de tabla y campo. La alta posibilidad de romper la aplicación después de cambiar el nombre de una entidad DB y perder algunas referencias a ella en algún lugar.
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 / mapeo en un solo lugar.

(-)

El rendimiento puede ser peor
Ningún o poco control sobre SQL que produce el ORM (podría ser ineficiente o peor con errores). Es posible que deba 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 origen).
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 versus estar restringido en lo que puede hacer, pero hacerlo rápidamente.

No hay una respuesta general a esta pregunta. Es una cuestión de guerras santas. También depende de un proyecto en cuestión y sus necesidades. Elige lo que mejor te funcione.

— AGuyCalledGerald
fuente

47

No creo que los puntos con respecto al control de la fuente sean relevantes. El esquema de la base de datos, los procedimientos almacenados, los UDF, etc. pueden estar y deben estar bajo el control de la fuente.

— Lee Gunn

15

+1 paraAs any abstraction can produce "high-level" developers having no idea how it works under the hood

— nawfal

3

De acuerdo, el argumento de control de origen es incorrecto. Siempre almacenamos nuestros scripts de creación de bases de datos en svn. ¿Cómo puede incluso mantener la base de datos fuera del control de la fuente al desarrollar una aplicación de base de datos?

— Wout

3

EF no es realmente adecuado para alta disponibilidad y alto rendimiento, no soy un tipo de DBA pero no veo lo que ofrece EF que hace que sea más fácil de codificar.

— Jamie

44

Por lo tanto, estamos renunciando a la flexibilidad, el control total y el rendimiento para el "desarrollo rápido" y evitando cambios de código si cambia DB. A mí me parece pura pereza.

— user2966445

18

su pregunta es básicamente O / RM vs mano escribiendo SQL

¿Usa un ORM o SQL simple?

Eche un vistazo a algunas de las otras soluciones O / RM que existen, L2S no es la única (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 normalmente es mucho más rápido usando un O / RM una vez que asimilas el proceso
El código también suele ser mucho más ordenado y más fácil de mantener
SQL directo, por supuesto, le dará más flexibilidad, pero la mayoría de los O / RM pueden hacer todas las consultas menos las más complicadas
En general, sugeriría ir con un O / RM, la pérdida de flexibilidad es insignificante

— BlackICE
fuente

@David Gracias, pero no es ORM vs SQL. Estoy buscando mudarme a ORM y me pregunto en qué invertir tiempo para aprender: EF o L2S (a menos que sean basura en comparación con los Stored Procs)

— BritishDeveloper

1

Definitivamente, diría que no son basura en comparación con los procesos almacenados, y un beneficio adicional es que no tiene código extendido a la base de datos. Personalmente, me gusta L2S, pero no he hecho mucho con EF en este momento, y parece que L2EF lo va a suplantar, así que iría EF. Además, una vez que va a Linq, no regresa.

— BlackICE

13

LINQ-to-SQL es una pieza notable de tecnología que es muy simple de usar y, en general, genera muy buenas consultas en el back-end. LINQ-to-EF estaba programado para suplantarlo, pero históricamente ha sido extremadamente difícil de usar y generó SQL muy inferior. No sé el estado actual de las cosas, pero Microsoft prometió migrar todas las bondades de L2S a L2EF, por lo que tal vez todo esté mejor ahora.

Personalmente, tengo una aversión apasionada por las herramientas ORM (vea mi diatriba aquí para más detalles), por lo que no veo ninguna razón para favorecer a 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 solo soy yo. ;-)

— Marcelo Cantos
fuente

1

L2S es bastante bueno, pero tiene la desventaja de que Microsoft ha declarado que básicamente no van a invertir mucho en extenderlo. Puede ver los resultados de esto ya en la última versión que solo tiene algunas correcciones de errores y algo de soporte para los tipos de datos de SQL Server 2008 agregados.

— FinnNk

De acuerdo, @FinnNk. Es una realidad desafortunada que usar L2S es algo arriesgado debido a su estado paria. Pero si realmente lo engañaron completamente a favor de L2EF, sospecho firmemente que habría una ruta de migración, debido a lo siguiente que aún disfruta.

— Marcelo Cantos

3

Linq to EF ha madurado y ahora produce SQL tan bueno como L2S (a partir de .NET 4.0). L2EF es mucho mejor que L2S hoy en día, ya que al menos puede actualizar su modelo a medida que cambia la base de datos, lo que L2S nunca podría hacer automáticamente. También me gusta el hecho de que puede mapear relaciones simples M: M con EF como relaciones sin necesidad de tener una entidad intermedia. Hace que el código sea mucho más limpio.

— Dave Markle

2

Gracias por la actualización @Dave. No estoy de acuerdo con el comentario M: M, sin embargo. Los esquemas con los que he trabajado casi siempre crecen atributos adicionales en las tablas de unión. Esto induce un cambio estructural en el modelo de objetos, que requiere una gran cantidad de modificaciones de código. Prefiero tratar la relación intermedia explícitamente desde el principio.

— Marcelo Cantos

1

Es posible que desee considerar un enfoque completamente nuevo si lo que busca es la potencia y el rendimiento de los procedimientos almacenados, y el rápido desarrollo que proporcionan herramientas como Entity Framework.

Tomé SQL + para una prueba de manejo en un proyecto pequeño, y realmente es algo especial. Básicamente agrega lo que equivale a comentarios a sus rutinas SQL, y esos comentarios proporcionan instrucciones a un generador de código, que luego construye una biblioteca de clases orientada a objetos realmente agradable basada en la rutina SQL real. Tipo de marco de entidad similar a la inversa.

Los parámetros de entrada se vuelven parte de un objeto de entrada, los parámetros de salida y los conjuntos de resultados se vuelven parte de un objeto de salida, y un componente de servicio proporciona las llamadas al método.

Si desea utilizar procedimientos almacenados, pero aún desea un desarrollo rápido, es posible que desee echar un vistazo a estas cosas.

— Vincent
fuente