entre - Entity Framework VS LINQ a SQL VS ADO.NET con procedimientos almacenados?

diferencias entre ado.net y entity framework

Question

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

1. Actuación
2. Velocidad de desarrollo
3. Código limpio, intuitivo y fácil de mantener.
4. Flexibilidad
5. En general

Me gusta mi SQL y, por lo tanto, siempre he sido un gran fanático de ADO.NET y los procedimientos almacenados, pero recientemente tuve un juego con Linq to SQL y me sorprendió lo rápido que estaba escribiendo mi capa DataAccess y decidí gastar ¿Algún tiempo realmente entendiendo Linq a SQL o EF ... o ninguno?

Solo quiero comprobar, que no hay una gran falla en ninguna 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 lejos.

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

Answer 1

En primer lugar, si está iniciando un nuevo proyecto, vaya con Entity Framework ("EF"): ahora genera mucho mejor SQL (más como Linq a SQL) y es más fácil de mantener y más poderoso que Linq a 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 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á 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 manera que el marco no tenga que regenerar constantemente el SQL, o que tenga problemas de escalabilidad. (ver ediciones)

Para las actualizaciones masivas en las que está actualizando grandes cantidades de datos, el SQL sin procesar o un procedimiento almacenado siempre tendrán un mejor desempeño 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 procedimientos almacenados / SQL 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 (si lo solicita), para que no tenga problemas de sincronización entre su código de objeto y su código de base de datos. La única vez que no consideraría el uso de un ORM es cuando está realizando una aplicación de tipo de 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 limpio / mantenible

Sin duda, EF supera a SQL / sprocs. Debido a que sus relaciones están modeladas, las uniones en su código son relativamente infrecuentes. Las relaciones de las entidades son casi evidentes para el lector en la mayoría de las consultas. Nada es peor que tener que pasar de la depuración de nivel a nivel o a través de múltiples niveles de SQL / nivel intermedio para comprender lo que realmente está sucediendo con sus datos. EF trae su modelo de datos a su código de una manera muy potente.

4) Flexibilidad

Procs almacenados y SQL en bruto 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ácilmente que con ORM.

5) En general

No se deje atrapar por la falsa dicotomía de elegir un ORM frente a los procedimientos almacenados. Puedes usar ambos en la misma aplicación, y probablemente deberías. Las operaciones masivas grandes deben ir en procedimientos almacenados o SQL (que en realidad puede llamar el EF), y EF debe usarse para sus operaciones CRUD y la mayoría de las necesidades de su nivel medio. Quizás elegirías usar SQL para escribir tus informes. Supongo que la moraleja de la historia es la misma que siempre ha sido. Utilice la herramienta adecuada para el trabajo. Pero lo flaco de esto es que EF es muy bueno hoy en día (a partir de .NET 4.0). Dedica algo de tiempo para leerlo y comprenderlo en profundidad, y podrás crear fácilmente aplicaciones sorprendentes de alto rendimiento.

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

Answer 2

LINQ-to-SQL es una pieza notable de tecnología que es muy simple de usar y, en general, genera muy buenas consultas al final. LINQ-to-EF fue programado para suplantarlo, pero históricamente ha sido extremadamente torpe de usar y ha generado un SQL muy inferior. No conozco el estado actual de las cosas, pero Microsoft prometió migrar toda la bondad de L2S a L2EF, por lo que quizás todo esté mejor ahora.

Personalmente, me apasionan las herramientas de ORM (vea mi diatriba here para conocer los detalles), por lo que no veo ninguna razón para favorecer a L2EF, ya que L2S me brinda todo lo que siempre espero que necesite 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 añaden una complejidad completamente innecesaria. Pero eso es sólo yo. ;-)

Answer 3

tu pregunta es básicamente la escritura a mano de O / RM vs SQL

¿Usando un ORM o SQL simple?

Eche un vistazo a algunas de las otras soluciones de 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:

1. Depende de la calidad de la solución O / RM, L2S es bastante bueno para generar SQL
2. Normalmente, esto es mucho más rápido usando un O / RM una vez que desarrolle el proceso
3. El código también suele ser mucho más ordenado y más fácil de mantener.
4. Por supuesto, Straight SQL le proporcionará más flexibilidad, pero la mayoría de O / RM puede hacer todo menos las consultas más complicadas
5. En general, sugeriría ir con una O / RM, la pérdida de flexibilidad es despreciable

Answer 4

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 de base de datos 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 / asignaciones en un solo lugar.

(-)

• El rendimiento puede ser peor
• Ningún o poco control sobre el SQL que produce el ORM (podría ser ineficiente o un buggy peor). Es posible que deba intervenir y reemplazarlo con procedimientos almacenados personalizados. Eso hará que su código sea desordenado (algunos LINQ en el código, algunos SQL en el 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 en lugar de restringirte en lo que puedes hacer, pero hacerlo de manera muy rápida.

No hay una respuesta general a esta pregunta. Es una cuestión de guerras santas. También depende de un proyecto a la mano y de tus necesidades. Recoge lo que mejor funcione para ti.