[Khaine]

#csharp #programowanie

Ostatnio natknąłem się na pewien problem w postaci słabej elastyczności ręcznie rzeźbionych configów i zastanawiam się co z nim zrobić.

Zrobiłem sobie w projekcie osobną .dll w której to trzymam przeróżne statyczne narzędziówki które niekoniecznie są powiązane z jakimś konkretnym projektem i mogą być też używane w innych - mamy tam zrobiony na gotowo odczyt plików (to UWP, więc tam nie jest tak hop siup z tym), jakieś logi czy odczytywanie configów z XML właśnie.

No i pojawia się tutaj pewien problem - bo z tych configów korzysta także ta dll. Zasila ona konfiguracją zarówno siebie samą jak i aplikację, żeby było w jednym miejscu. Ostatnio powstała nowa aplikacja w której te narzędziówki zamknięte w .dll się bardzo przydały, ale rzezanie konfigów do takiego poziomu aby było tylko to minimum potrzebne samej dllce aby dolepić nowe pola nie do końca się udało -> bo klasa będąca obiektem przechowującym konfigurację, ma z jedno czy dwa pola z których ta .dll korzysta pod warunkiem, że główna aplikacja chce korzystać z pewnych ficzerów - a to nie zawsze nastąpi.

W C# generalnie wywalenie tego pola z klasy AppSettings od razu sprawi, że nam się to nie skompiluje. Nie za bardzo mam ochotę na dalszą dekompozycję tych bibliotek żeby mieć w przyszłości pierdylion projektów z dwoma funkcjami statycznymi na krzyż i wszystkie z zapiętą referencją na tą bibliotekę narzędziową -> więc pierwsze co przychodzi mi do głowy to zamiast obiektu klasy AppSettings zrobić po prostu dynamic do którego rozparsujemy każdy XML czy JSON a potem zamontować na ConfigProviderze (to statyczna klasa która daje dostęp do settingsów) jakieś przeciążenie np. operatora [ ] pod którym będzie try / catch rzygający w użytkownika błędem jak w tym obiekcie nie znajdzie szukanej właściwości a jest mu do czegoś potrzebna.

Jest jakieś inne sprytne i zgeneralizowane podejście na które nie wpadłem? Tak żeby w przyszłości nie musieć się znowu zastanawiać, co zrobić jak w aplikacji X potrzebuję innego configa niż w Y, ale generalnie 90% narzędziówki się przyda? Generyki też średnio tutaj pasują, bo biblioteka nadal by wołała o pewne pola które mogą jej teoretycznie być potrzebne - gdyby tylko aplikacja miała pewnej funkcjonalności używać -> np. zdolności do samodzielnego łączenia i zarządzania WiFi, które też tam się znajduje (a to ledwo jedna klasa z paroma funkcjami).

[bacteria]

@Khaine: do statycznych Niezwiązanych z configiem uzywasz jednej dllki a do dynamucznych np. Yaml dziala wysmienicie. Jak nie potrzebujesz strongly typed to nawet zwykly deserializer json.net mozesz użyć

[Khaine]

@bacteria: Problem jest właśnie w tym, że one są warunkowo związane. Jak nie używasz pewnego ficzera to po prostu może nie być tam np. SSID oraz hasła do WiFi, no bo po kiego grzyba? A dll tego potrzebuje i będzie o to kwiczeć żeby jednak w obiekcie ustawień się znajdowało (nawet jako null, chodzi o samo pole).

Ta biblioteka to takie coś w stylu "bullshit który najprawdopodobniej przyda ci się w

[object]

@Khaine: chyba nie bardzo zrozumiałem problem. Może generyki i jakaś kolekcja typu feature?

[hinduss]

@Khaine: Zamiast korzystać z ApplicationSettings wykorzystaj ConfigurationManager. Wrzucasz, jeśli potrzebujesz setting do configa a w dll po prostu sprawdzasz, czy setting o danym kluczu występuje. https://bauermalzwei.de/2019/01/03/appsettings-vs-applicationsettings-in-c/