Async/Warte in mehrschichtigen C# -Anwendungen

Question

Ich habe eine mehrschichtige C# MVC4-Webanwendung in einem stark frequentierten Szenario, das Dependency Injection für verschiedene Repositorys verwendet. Dies ist sehr nützlich, da es leicht testbar ist, und in der Produktion können wir die Repositories für bestimmte Controller leicht konfigurieren. Alle Controller erben von AsyncController, so dass Aktionsmethoden, die Task<JsonResult> oder Task<ActionResult> zurückgeben, wirklich unserem Server helfen, mit mehr Benutzern und solve for the dreaded thread starvation problem zu skalieren. Einige Repositories verwenden Webdienste, die wir definitiv mit Async/Await nutzen können, um Skalierbarkeit zu bieten. In anderen Fällen können einige nicht verwaltete Dienste verwenden, die nicht sicher verlegt werden können und bei denen async/await keine Vorteile bietet. Jedes Repository ist eine Implementierung einer Schnittstelle, IRepository. Kurz gesagt, jede Implementierung unterscheidet sich drastisch in der Art, wie sie Daten erhalten kann. Diese Konfiguration wird zum Zeitpunkt der Bereitstellung mit web.config-Änderungen und Autofac-Modulen ausgewählt.

Was sind einige der empfohlenen Wege zur Implementierung von async/await in einer Anwendung wie dieser? Um das Muster in meiner vorhandenen Anwendung anzupassen, muss ich die Schnittstelle ändern, um Task<MyBusinessObject> zurückzugeben. Aber ist das nicht mehr ein Implementierungsdetail? Ich könnte zwei Methoden Stubs zur Verfügung stellen, GetData und GetDataAsync, aber für mich würde das die Flexibilität nicht erlauben, die ich jetzt mit IoC-Frameworks wie Autofac habe, wo ich leicht alles aus tauschen kann, ohne Code ändern zu müssen.

Einer der Microsoft-Entwickler für Async/Await hat einen Blog-Beitrag veröffentlicht, "Should I expose an asynchronous wrapper for my synchronous methods?", der in das Problem eingeht. Wenn Ihre asynchrone Methode nicht wirklich asynchron ist (dh native E/A-Vorteile bietet), wird nur ein Overhead hinzugefügt. Mit anderen Worten, es bietet keine Skalierbarkeitsvorteile.

Ich möchte nur, wie der Rest der Gemeinschaft dieses Problem angegangen ist.

Answer 1

In Ihrer Situation, empfehle ich Ihre Schnittstellen asynchron zu machen:

public interface IMyInterface 
{ 
    Task<TMyResult> GetDataAsync(); 
} 

Für synchrone Methoden können Sie Task.FromResult zurück:

public class MyImplementation : IMyInterface 
{ 
    public Task<TMyResult> GetDataAsync() 
    { 
    TMyResult ret = ...; 
    return Task.FromResult(ret); 
    } 
} 

Asynchrone Methoden natürlich async und await verwenden werden können.

In Bezug auf die Implementierungsdetails würde ich "Ja und Nein" sagen. ;) In dieser Hinsicht ist es IDisposable sehr ähnlich. Logischerweise ist es ein Implementierungsdetail in dem Sinne, dass es keine Rolle spielt, in welcher Weise es implementiert wird. Es ist nicht ein Implementierungsdetail in dem Sinne, dass der aufrufende Code anders damit umgehen muss. Ich stimme also zu, dass dies logischerweise ein Implementierungsdetail ist, aber dass die .NET-Plattform nicht ausreichend fortgeschritten ist, um sie als solche zu behandeln.

Alternativ können Sie daran denken, wie diese (die Erklärung ist, ich in der Regel geben): async ist die tatsächliche Umsetzung Detail, und wenn Sie Task<T> statt T zurückkehren, sind definieren Sie eine Schnittstelle, wo die Umsetzung kann asynchron sein.

Ich habe eine series of blog posts, die Adressierung mit async "in der großen" (d. H. Anpassung async in mit OOP, anstatt zu ermöglichen, dass es funktionsfähig ist). Ich behandle einige allgemeine Probleme wie asynchrone Initialisierung und IoC. Es ist nur die Meinung einer Person, aber mir sind keine anderen Ressourcen für diese Art von Problemen bekannt.

P.S. Sie müssen in MVC4 nicht mehr von AsyncController erben. Der Standard-Controller-Handler erkennt automatisch async Methoden anhand ihres Rückgabetyps (Task oder Task<T>).

Answer 2

Aufgabe ist eine undichte Abstraktion. Wenn Sie die Verwendung von IO-Completion-Port-Threads nutzen möchten, müssen Sie Tasks vollständig von Ihren Repositorys zu Ihren Controllern zurückgeben.

Obwohl die gesamte Call-Stack-Rückgabe Task<T> die Skalierbarkeit verbessern kann, fügt sie Ihrer Anwendung eine zusätzliche Komplexitätsebene hinzu. Dies behindert die Wartbarkeit und Testbarkeit und erschwert das Nachdenken über Code. Asynchronous code will always be harder than synchronous code.

Persönlich, ich eher die Menge an Speicher des Servers erhöhen und konfigurieren Sie die Anwendung einen größeren Threadpool zu haben, um den Verlust der Skalierbarkeit zu kompensieren, oder skalieren Sie auf ein paar zusätzliche (virtuelle) Server, anstatt dieses zusätzliche hinzuzufügen Komplexität.