rocedimientos almacenados de @Entity Framework vs SQL generado

He usado el marco de la entidad en un par de proyectos. En cada proyecto, he utilizado procedimientos almacenados asignados a las entidades debido a los bien conocidos beneficios de los procedimientos almacenados: seguridad, mantenimiento, etc. Sin embargo, el 99% de los procedimientos almacenados son procedimientos almacenados CRUD básicos. Parece que niega una de las principales características de ahorro de tiempo de Entity Framework: la generación de SQL.

He leído algunos de los argumentos con respecto a los procedimientos almacenados en comparación con el SQL generado del Entity Framework. Si bien el uso de SP CRUD es mejor para la seguridad, y el SQL generado por EF a menudo es más complejo de lo necesario, ¿realmente compra algo en términos de rendimiento o facilidad de mantenimiento para usar SP?

Esto es lo que creo:

La mayoría de las veces, modificar un SP requiere actualizar el modelo de datos de todos modos. Por lo tanto, no está comprando mucho en términos de mantenibilidad.Para aplicaciones web, la conexión a la base de datos utiliza una única ID de usuario específica para la aplicación. Por lo tanto, los usuarios ni siquiera tienen acceso directo a la base de datos. Eso reduce el beneficio de seguridad.Para una aplicación pequeña, el rendimiento ligeramente disminuido del uso de SQL generado probablemente no sería un gran problema. Para aplicaciones de alto volumen y rendimiento crítico, ¿EF sería incluso una buena elección? Además, ¿son realmente malas las instrucciones de inserción / actualización / eliminación generadas por EF?Enviar cada atributo a un procedimiento almacenado tiene sus propias penalizaciones de rendimiento, mientras que el código generado por EF solo envía los atributos que realmente se modificaron. Al realizar actualizaciones en tablas grandes, el aumento del tráfico de red y la sobrecarga de actualizar todos los atributos probablemente niega el beneficio de rendimiento de los procedimientos almacenados.

Con eso dicho, mis preguntas específicas son:

¿Son correctas mis creencias mencionadas anteriormente? ¿La idea de usar siempre SP es algo que es "de la vieja escuela" ahora que los ORM están ganando popularidad? En su experiencia, ¿cuál es la mejor manera de ir con EF: mapear SP para todas las inserciones / actualizaciones / eliminaciones, o usar SQL generado por EF para operaciones CRUD y solo usar SP para cosas más complejas?

Respuestas a la pregunta(5)

Su respuesta a la pregunta