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

Question

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

1. Rendimiento
2. Velocidad de desarrollo
3. aseado, intuitivo, código mantenible
4. Flexibilidad
5. general

I como mi SQL, así que siempre he sido un fan incondicional de ADO.NET y de los procedimientos almacenados, pero recientemente tuve un juego wi th Linq to SQL y quedé impresionado por la rapidez con la que estaba escribiendo mi capa de DataAccess y he decidido dedicar algo de tiempo a comprender realmente Linq to SQL o EF ... ¿o ninguno?

Solo quiero comprobar que no hay un gran defecto en ninguna de estas tecnologías que haga que mi tiempo de investigación sea inútil. P.ej. el rendimiento es terrible, es genial para aplicaciones simples, pero solo puede llevarlo tan lejos.

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

Answer 1

Primero, si estás comenzando un nuevo proyecto, vaya con Entity Framework ("EF") - ahora genera mucho mejor SQL (más parecido a Linq a SQL) y es más fácil de mantener y más poderoso que Linq to SQL ("L2S"). Desde el lanzamiento de .NET 4.0, considero que Linq to SQL es una tecnología obsoleta. MS ha sido muy abierto 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 entidad única (CRUD), encontrará casi el mismo rendimiento con las tres tecnologías. Debes saber cómo funcionan EF y Linq to SQL para utilizarlos al máximo. Para operaciones de alto volumen como consultas de sondeo, es posible que desee que EF/L2S "compile" la consulta de su entidad de manera que el marco no tenga que regenerar constantemente el SQL, o puede encontrarse con problemas de escalabilidad. (ver ediciones)

Para las actualizaciones masivas en las que está actualizando cantidades masivas de datos, SQL sin formato o un procedimiento almacenado siempre tendrá un mejor rendimiento que una solución ORM porque no tiene que ordenar los datos a través del cable. ORM para realizar actualizaciones.

2) velocidad de desarrollo

En la mayoría de los escenarios, EF soplará/SQL procedimientos almacenados lejos 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 se encuentre con problemas de sincronización entre su código objeto y su código de base de datos. La única vez 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 formato en una base de datos.

3) Neat/Código Mantenible

Sin duda, EF latidos/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 para la mayoría de las consultas. No hay nada peor que tener que pasar de la depuración de nivel a nivel oa través de múltiples SQL/nivel medio para comprender qué está pasando con sus datos. EF trae su modelo de datos a su código de una manera muy poderosa.

4) Flexibilidad

procs almacenados y SQL primas son más "flexible". 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 que con y ORM.

5) En general

No se deje atrapar en el false dichotomy de elegir un ORM vs uso de procedimientos almacenados. Puede usar ambos en la misma aplicación, y probablemente debería. Las operaciones masivas deben ir en procedimientos almacenados o SQL (que en realidad puede ser llamado por EF), y EF debe usarse para sus operaciones CRUD y la mayoría de las necesidades de su nivel medio. Tal vez elegirías usar SQL para escribir tus informes. Supongo que la moraleja de la historia es la misma que siempre ha sido. Use la herramienta correcta para el trabajo. Pero lo flaco de esto 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 podrá crear algunas aplicaciones increíbles de alto rendimiento con facilidad.

EDITAR: EF 5 simplifica esta parte un poco con auto-compiled LINQ Queries, pero por cosas de alta volumen real, definitivamente se necesita para probar y analizar lo que se ajusta 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 en el back-end. LINQ-to-EF estaba destinado a suplantarlo, pero históricamente ha sido extremadamente torpe para usar y generó SQL muy inferior. No sé cuál es el estado actual de las cosas, pero Microsoft prometió migrar todas las bondades de L2S a L2EF, así que quizás todo esté mejor ahora.

Personalmente, tengo una aversión apasionada por las herramientas ORM (vea mi diatriba here para los detalles), así que no veo ninguna razón para favorecer L2EF, ya que L2S me da todo lo que espero 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 complejidad completamente innecesaria. Pero solo soy yo. ;-)

Answer 3

Los procedimientos almacenados:

(++)

• gran flexibilidad
• Control total sobre SQL
• El mayor rendimiento disponible

(- -)

• se requieren conocimientos de SQL
• Los procedimientos almacenados están fuera del control de la fuente
• cantidad sustancial de "repetir siempre lo mismo", mientras que la especificación de los mismos nombres de tabla y campo. La alta probabilidad de romper la aplicación después de cambiar el nombre de una entidad DB y perder algunas referencias a ella en alguna parte.
• Desarrollo lento

ORM:

(+)

• El rápido desarrollo
código de acceso de datos
• ahora bajo control de origen
• Usted está aislado de los cambios en DB. Si eso sucede, solo necesita actualizar su modelo/mapeos en un solo lugar.

(-)

• el rendimiento puede ser peor
• poco o ningún control sobre SQL produce el ORM (podría ser ineficaz con errores o peor). Podría necesitar intervenir y reemplazarlo con procedimientos almacenados personalizados. Eso desorganizará su código (algunos LINQ en código, algunos SQL en código y/o en DB fuera de control de fuente).
• Como cualquier abstracción puede producir desarrolladores "alto nivel" sin tener idea de cómo funciona bajo el capó

---

La desventaja general es entre tener una gran flexibilidad y perder mucho tiempo frente está restringido en lo que puedes hacer pero teniendo que hacerlo muy rápido.

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

Answer 4

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

Using an ORM or plain SQL?

Tome 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 cuestiones específicas:

1. depende de la calidad de la solución/RM O, L2S es bastante buenos para la generación de SQL
2. Esto es normalmente mucho más rápido usando un O/RM una vez que asimilo el proceso
3. Código también suele ser mucho más limpio y más fácil de mantener
4. recta SQL, por supuesto, se obtiene una mayor flexibilidad, pero la mayoría de O/de puede hacer todo, pero las consultas más complicadas
5. en general, sugeriría ir con un O/RM RM, la pérdida de la flexibilidad es insignificante