Ämnet Generic Host / appdesign

Det här ämnet handlar om

När en .NET-app växer lite sprids Main, Program.cs, initiering av formulär, bakgrundsarbete som körs hela tiden, inläsning av konfiguration och start av loggning ut över koden. Det här ämnet är en samlingspunkt för att följa hur hela appens start och stopp ska utformas, med Generic Host som utgångspunkt.

• var DI, konfiguration och loggning ska kopplas ihop
• vem som äger livslängden för BackgroundService och annat bakgrundsarbete som körs hela tiden
• hur kontrollerad nedstängning (graceful shutdown) och slutlig flush vid stopp hanteras
• hur man ordnar det arbete som ligger utanför användargränssnittet

Frågor som ofta dyker upp i rådgivning

• Task.Run och timers har dykt upp överallt, och ansvaret för att stoppa dem är oklart
• man är osäker på hur långt Host.CreateApplicationBuilder och BackgroundService bör användas
• man vill ordna en gemensam grund för konsolverktyg, worker-processer och skrivbordsappar
• koppling av konfiguration, loggning och DI har byggts på i efterhand, bit för bit, och har blivit svår att hantera

Ett arbetssätt som brukar fungera

Det hjälper föga att bara lära sig API-namnen för Generic Host. Det blir enklare att få ordning om man ser start, livslängd och ansvarsfördelning tillsammans. Utgå från de tre relaterade artiklarna och läs dem tillsammans med sidorna om Windows-apputveckling och designgranskning, så blir det tydligt hur långt hosten bör sträcka sig.

Relaterade artiklar

Rådfråga oss här

Om den här sidan liknar den situation du står inför kan du rådfråga oss och beskriva nuläget och vilken typ av stöd du behöver.