Konfiguracja aplikacji bez ifowania w kodzie? Tak, wszystko dzięki dobrym i mądrym “chłopakom” z Microsoftu. Czytam o dotnet core oraz o tym jak można dobrze ustawić konfiguracje aplikacji od środowiska na którym zostanie uruchomione i chce się z wami podzielić tą wiedzą, uważam że pomoże ona wam (mi też) w lepszym i czytelniejszym przygotowywaniu  konfigurowaniu.

Poniżej kilka przykładów na to jak do tego tematu podejść.

Konfiguracja aplikacji na podstawie plików:

W tym przypadku do domyślnej (@8) konfiguracji dołączany jest także plik. Który? To zależy od środowiska, nazwa środowiska jest zawarta w nazwie pliku (@9). Sam plik rozszerza ustawienia lub je zastępuje, oba przypadki są wspierane.

To jest pierwsza z opcji jak można wpływać na ustawienia aplikacji w zależności od środowiska na którym się uruchamia.

Konfiguracja aplikacji na podstawie nazwy metody

Idąc dalej i czyniąc kod trochę czytelniejszym, można dołożyć do klasy startup metody które w swojej nazwie posiadają nazwę specyficzną dla środowiska:

Powyżej widać metody ConfigureServices które zostały wzbogacone o nazwy środowisk na których mogą być uruchomione i w zależności od tego  aplikacja może zachowywać się inaczej. Inaczej to inne poziomy logowania, inne zachowanie aplikacji.

• ConfigureOstrapilaServices
• ConfigureStadnickiServices
• ConfigureProductionServices

ConfigureServices – ta metoda zostanie uruchomiona gdy nazwa środowiska jest pusta, lub nie zostanie odnaleziona metoda pasująca do nazwy. Tzw. fallback

Konfiguracja aplikacji na podstawie klasy

Ostatnią z możliwości jest przepięcie całej klasy, całość wygląda podobnie do poprzedniego przykłady z metodą, ale w tym przypadku cała klasa zostanie wykorzystana do konkretyzacji konfiguracji, wymaga to odrobinę innego startu aplikacji:

Jako starup podaję się namespace, który zawierać powinien definicję klasy Startup lub BlahStartup gdzie Blah to nazwa środowiska, przykłady:

Lub domyślny w przypadku nie dopasowania nazwy środowiska czy brak nazwy środowiska:

Uwaga, ominąłem metodę ConfigureService aby zaoszczędzić miejsca, ale każda z tych klas to pełnowartościowy startup aplikacji, także można dowolnie poszaleć i w zasadzie odpalić całkowicie inną aplikację.

Czyli co?

Cieszy mnie to, że w zależności od środowiska w prosty i czytelny sposób mam wpływ na to co i jak zostanie skonfigurowane. Cieszy mnie to, że wszystko to zostało tak ładnie obmyślone i wystarczy zmiana wartości ASPNETCORE_ENVIRONMENT aby mieć wpływ to jako cała aplikacja będzie działać inaczej.

Kod dostępny jest pod linkiem:
https://bitbucket.org/jstadnicki/