Traemos la mejor respuesta que hemos encontrado en línea. Queremos que te sea de ayuda y si deseas comentarnos alguna mejora hazlo libremente.
Solución:
Hay algunas cosas que puede hacer para optimizar su consulta. Aquí en MSDN puede encontrar una buena descripción general.
Pero para ser honesto, un procedimiento almacenado con mapeo manual siempre tendrá un rendimiento más rápido. Pero pregúntese, ¿qué tan importante es el rendimiento? En la mayoría de los proyectos, el tiempo de desarrollo es mucho más importante que el rendimiento. ¿Qué fue más difícil de desarrollar? ¿La consulta sin procesar con análisis o la consulta de Entity Framework?
Los ORM no están diseñados porque funcionan mucho mejor que un enfoque escrito a mano. ¡Los usamos porque el desarrollo es mucho más fácil!
Si escribe su aplicación con Entity Framework y oculta todas sus consultas detrás de un patrón de repositorio, puede desarrollar rápidamente y luego, cuando el rendimiento se convierte en un problema, medir su aplicación para detectar el cuello de botella. Entonces, tal vez algunas de sus consultas necesiten optimización y se puedan mover a procedimientos almacenados y mapeo manual.
De acuerdo con @Wouter de Kort… Además, cuando necesite pasar a los procedimientos, puede usar EF junto con los procedimientos para ayudar en la migración de uno a otro.
Pasar a los procedimientos será más rápido en una aplicación típica si unificar la funcionalidad en procedimientos bien diseñados. es decir, hacer la mayor cantidad de trabajo en uno llamada sproc como sea posible. Por ejemplo, en una aplicación MVC de carrito de compras cuando un usuario hace clic en el botón de pago, usted podría usa el ORM para algo como:
- busque la autenticación de un usuario (¿el inicio de sesión sigue siendo válido?)
- buscar permisos (¿pueden comprar dichos artículos?, ¿hay requisitos especiales?)
- buscar cantidades de existencias para asegurarse de que no se agotaron en el proceso
- escriba a DB para reservar (eliminar del inventario disponible) artículos antes del pago
- buscar información de pago
- Inicio sesión … ?
O pueden ser pasos completamente diferentes, pero en cualquier caso, el punto es que la aplicación MVC utilizará un ORM para realizar varias llamadas a la base de datos para llegar al siguiente paso.
Si toda esta lógica está encapsulada en un sproc bien escrito, entonces solo hay una llamada al sproc y listo. Con la ruta MVC-ORM, los datos deben copiarse de la base de datos al controlador y entregarse a ORM (generalmente a través de la red a un host diferente) y luego leerse mediante la aplicación MVC para tomar una decisión simple y luego repetirse hasta que se completen todos los pasos. . En el caso de usar un sproc que encapsule ese paso de verificación, hay mucho menos que copiar y mover datos, menos E/S de red, menos cambio de contexto, etc.
Piense en la solución MVC-ORM de esta manera. La persona “A” solo conoce los hechos y la persona “B” tiene toda la inteligencia para tomar decisiones con hechos dados que él no plantea. La persona “B” envía correos electrónicos a “A” para obtener información. Según la respuesta de “A”, “B” podría solicitar algunos datos más antes de tomar una decisión. Eso es un montón de mensajes de ida y vuelta.
Si tiene una persona que tiene todos los hechos y el conocimiento para tomar decisiones, solo necesita hacer una pregunta y su cerebro procesará todo internamente para encontrar una respuesta. No hay deliberación con otra persona involucrada. Naturalmente, va a ser más rápido.
Eso no quiere decir que sea necesariamente mejor. Separar los hechos de la decisión significa que estos componentes son reemplazables / comprobables por separado; sin embargo, si está casado con su MVC y su base de datos, entonces eso no es un “problema”.
Por otro lado, muchos fanáticos de MVC odian escribir SQL, por lo que consideran que poner cualquier lógica de decisión en SQL es un desastre natural. Para tales personas, es imperativo tener alguna lógica escrita en el mismo lenguaje que usa el MVC porque acelera el desarrollo para ellos. En algunos casos, esto tampoco es un “problema”, ya que en el caso de algunos RDMBS puede escribir sprocs en el mismo lenguaje que el utilizado por MVC (ejemplos: .Net – SQL Server sprocs puede escribirse en C# y usar .Net; las funciones de Postgresql (sin sprocs) se pueden escribir en Perl, Python, PHP y otros) La ventaja en este caso es que puede tener sprocs rápidos que encapsulan varios pasos en una sola llamada y puede usar un lenguaje de programación que ya son rápidos en la codificación.
Es importante observar que
A partir de .NET Framework 4.5, las consultas LINQ son en cachéautomáticamente. Sin embargo, aún puede usar consultas LINQ compiladas para reducir este costo en ejecuciones posteriores y las consultas compiladas pueden ser más eficientes que las consultas LINQ que se almacenan automáticamente en caché.
Desde consultas compiladas de MSDN (LINQ a entidades)
Si te gusta la programación, tienes el poder dejar una crónica acerca de qué te ha impresionado de este ensayo.