Generic Host und App-Architektur

Was wir mit diesem Thema ordnen möchten

Wenn eine .NET-Anwendung etwas wächst, verteilen sich Main, Program.cs, die Initialisierung von Formularen, dauerhaft laufende Verarbeitung, das Laden der Konfiguration und die Initialisierung der Protokollierung über viele Stellen. Dieses Thema bündelt die Frage, wie Start und Stopp der gesamten Anwendung entworfen werden sollen, rund um den Generic Host.

• Wo DI, Konfiguration und Protokollierung verbunden werden
• Wer die Lebensdauer von BackgroundService und anderen dauerhaft laufenden Prozessen verantwortet
• Wie ein geordnetes Herunterfahren und das Flushen beim Beenden behandelt werden
• Wie Verarbeitung außerhalb der UI strukturiert wird

Häufige Themen in der Beratung

• Task.Run und Timer sind an vielen Stellen entstanden; dadurch bleibt die Verantwortung für das Beenden unklar.
• Es ist nicht klar, wie weit Host.CreateApplicationBuilder und BackgroundService eingeführt werden sollen.
• Für Konsolen-, Worker- und Desktopanwendungen soll eine gemeinsame Grundlage entstehen.
• Konfiguration, Protokollierung und DI wurden nachträglich ergänzt und sind dadurch schwer zu pflegen.

Ein passendes Vorgehen

Beim Generic Host hilft es wenig, nur API-Namen zu kennen. Klarer wird die Architektur, wenn Start, Lebensdauer und die Aufteilung der Verantwortlichkeiten gemeinsam betrachtet werden.

• Was .NET Generic Host ist
• Warum Generic Host / BackgroundService in Desktop-Apps sinnvoll ist
• Best Practices für C# async/await

Zusammen mit den Seiten zur Windows-App-Entwicklung und zur technischen Beratung machen diese drei Artikel deutlich, wie weit ein Host in die jeweilige Anwendung integriert werden sollte.

Verwandte Artikel

Kontakt aufnehmen

Wenn diese Seite zu Ihrer Situation passt, schildern Sie uns den aktuellen Kontext und die benötigte Unterstützung.