Esta pregunta se refiere al lenguaje C #, pero espero que cubra otros lenguajes como Java o TypeScript.
Microsoft recomienda mejores prácticas sobre el uso de llamadas asíncronas en la red. Entre estas recomendaciones, escojamos dos:
- cambie la firma de los métodos asíncronos para que devuelvan Tarea o Tarea < > (en TypeScript, sería una promesa < >)
- cambie los nombres de los métodos asíncronos para terminar con xxxAsync ()
Ahora, cuando se reemplaza un componente síncrono de bajo nivel por uno asíncrono, esto afecta la pila completa de la aplicación. Dado que async / await tiene un impacto positivo solo si se usa "hasta el final", significa que se deben cambiar los nombres de la firma y el método de cada capa en la aplicación.
Una buena arquitectura a menudo implica colocar abstracciones entre cada capa, de manera que la sustitución de componentes de bajo nivel por otras no se ve por los componentes de nivel superior. En C #, las abstracciones toman la forma de interfaces. Si introducimos un nuevo componente asíncrono de bajo nivel, cada interfaz de la pila de llamadas debe modificarse o reemplazarse por una nueva interfaz. La forma en que se resuelve un problema (asíncrono o sincronización) en una clase de implementación ya no está oculta (abstraída) para los llamadores. Las personas que llaman deben saber si es sincronización o asíncrona.
¿Las prácticas recomendadas no son asincrónicas / a la espera de los principios de "buena arquitectura"?
¿Significa que cada interfaz (por ejemplo, IEnumerable, IDataAccessLayer) necesita su contraparte asíncrona (IAsyncEnumerable, IAsyncDataAccessLayer) para que pueda ser reemplazada en la pila cuando se cambia a las dependencias async?
Si presionamos el problema un poco más, ¿no sería más sencillo asumir que todos los métodos son asíncronos (para devolver una Tarea < > o Promesa < >), y los métodos para sincronizar las llamadas asíncronas cuando ¿No son en realidad asíncronos? ¿Es esto algo que se puede esperar de los futuros lenguajes de programación?