puede - operaciones asincronas c#

¿Por qué el tutorial de EF 6 usa llamadas asíncronas? (3)

El último tutorial de EF que explica cómo usar EF 6 con MVC 5 parece inclinarse hacia el uso de llamadas asych a la base de datos como:

Department department = await db.Departments.FindAsync(id);

¿Es este el nuevo estándar / mejor práctica?

No estoy seguro de cuál es el beneficio para este estilo de desarrollo con ASP.NET MVC.

¿Alguien puede comentar sobre este patrón, este es el nuevo estándar que MS está promoviendo?

En ASP.NET, debe usar API asíncronas para todo lo relacionado con E / S, incluido el acceso a la base de datos y las llamadas al servicio web.

El uso de async permite a ASP.NET aprovechar al máximo el grupo de subprocesos, lo que genera beneficios de escalabilidad no triviales.

Lo ideal es que todo lo que implique un período de espera se haga de forma asincrónica. Una consulta de base de datos normalmente debe llamar a un servidor remoto, enviar la consulta y esperar a que el servidor responda con los resultados. Eso lo convierte en el principal candidato para la sincronización, ya que toda esa parte de "esperar a que el servidor responda" es una variable que no puede contabilizar en su aplicación.

El uso de asincronización permite que el servidor web reutilice el hilo actual para rellenar otras solicitudes web mientras el código espera que se complete la operación asincrónica. Cuando se completa, se devuelve un hilo a su aplicación para continuar el proceso. Si ejecuta la sincronización, mientras espera la base de datos o cualquier otro proceso que se ejecute durante mucho tiempo, el hilo se bloquea y no está disponible para el grupo del servidor web. Si hace esto lo suficiente, el servidor web puede quedarse sin subprocesos disponibles y debe comenzar a poner en cola nuevas solicitudes. Async mitiga esto al liberar subprocesos cuando están esperando algo, aumentando la carga potencial que su servidor web puede manejar.

Para decidir si desea sincronizar o sincronizar, compare los beneficios y los costos:

Asincrónico:

Casi nunca agota el grupo de hilos con asincrónico (las circunstancias tendrían que ser extremas)
Niveles de concurrencia bastante arbitrarios (solicitudes concurrentes y operaciones)
Ahorra 1MB de memoria por cada thread guardado
Concurrencia intra-solicitud segura gracias al SynchronizationContext
Puede aumentar la producción por porcentajes bajos de dos dígitos para casos de carga alta debido a la reducción de la sobrecarga de programación del sistema operativo. Dicho esto, casi ninguna aplicación de producción se encuentra bajo una alta carga de CPU, porque si así fuera, estaba cerca de la falta de disponibilidad (en el caso de un pico de carga, la aplicación comienza a eliminar solicitudes).

Sincronización:

Código más simple: await hace que el 99% de los casos (casi) sea tan simple como el código sincrónico. Dicho eso, las más de 10 preguntas asíncronas cada día en hablan un idioma diferente. Los casos extremos surgen cuando te desvías del camino simple. También cuando se usan bibliotecas heredadas que, por ejemplo, requieren que les proporcione una devolución de llamada sincrónica.
Menos trabajo para la codificación y la depuración
Perfil amigable (Puede crear un perfil de la aplicación o simplemente detener el depurador y ver qué está haciendo la aplicación en este momento. No es posible con la sincronización).
Interopera perfectamente con el código heredado y las bibliotecas

Elija una sincronización con ASP.NET si está llamando a servicios de latencia alta. Un servicio web es probable que tenga una alta latencia. Una base de datos OLTP es casi siempre de baja latencia.

Elija asincrónico si su aplicación se beneficia de niveles muy altos de concurrencia (más de 100). La mayoría de las aplicaciones no tienen niveles tan altos, o sus servicios de back-end no soportarían tal cantidad de carga. No tiene sentido hacer que la aplicación web escale pero sobrecargue el back-end. Todos los sistemas en la cadena de llamadas deben beneficiarse de un alto grado de concurrencia para que la sincronización sea beneficiosa.

Servicios típicos de alta latencia (buenos casos para asincrónico):

Servicios web
Esperando (por ejemplo, dormir)
Throttling ( SemaphoreSlim , ...)
Algunos servicios en la nube (Azure)
Consultas de larga duración a la base de datos (por ejemplo, informes o ETL)

Servicios típicos de baja latencia (buenos casos para la sincronización):

Llamadas a la base de datos: la mayoría de las consultas OLTP tienen baja latencia porque se puede suponer que el servidor de la base de datos no está sobrecargado. No tiene sentido lanzar cientos de consultas simultáneas. No los hace completar más rápido.
Sistema de archivos: lo mismo que las bases de datos.

Estos están categorizados por el caso típico . Todos estos pueden estar en la categoría opuesta también.

Puede mezclar sincronización y asincronización en la misma aplicación. Use asincrónico cuando esté en su punto óptimo.

Entonces, ¿por qué Microsoft y el equipo de Entity Framework promueven el uso asincrónico? Aquí viene la parte subjetiva de esta respuesta: podría ser la política interna de Microsoft. Es posible que anticipen el uso de EF en las aplicaciones cliente (para las cuales la sincronización es excelente). O bien, no se dan cuenta de que las llamadas de bases de datos asincrónicas casi siempre son una pérdida de tiempo de los desarrolladores sin beneficios. La mayoría de las personas no se dan cuenta de esto porque la asincrónica es el camino a seguir en estos días.