Jakie wzorce projektowe można zastosować do problemu z ustawieniami konfiguracji?

W dużych i złożonych produktach oprogramowanie Zarządzanie konfigurowalnymi ustawieniami staje się poważnym problemem. Dwa podejścia, które widziałem do problemu to:

  • niech każdy komponent w systemie załaduje własną konfigurację z plików konfiguracyjnych lub ustawień rejestru.
  • mają klasę settings loader, która ładuje wszystkie konfigurowalne ustawienia systemowe i kazdy komponent odpytywa program settings loader o jego ustawienia.

Te podejścia są dla mnie złe.

Czy istnieją jakieś wzorce projektowe, które można by wykorzystać do uproszczenia problemu? może coś, co wykorzysta technikę wtrysku zależności.

Author: paxos1977, 2009-08-22

3 answers

Wolę stworzyć interfejs do ustawiania zapytań, ładowania i zapisywania. Używając dependency injection, mogę wprowadzić to do każdego komponentu, który tego wymaga.

Pozwala to na elastyczność w zakresie zastępowania strategii konfiguracji i daje wspólną podstawę do działania. Wolę to niż pojedynczy, globalny "settings loader" (twoja opcja 2), zwłaszcza, że mogę zastąpić mechanizm konfiguracji dla pojedynczego komponentu, jeśli absolutnie muszę to zrobić.

 38
Author: Reed Copsey,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-22 00:24:24

Obecnie pracuję nad systemem, w którym konfiguracją zarządza jeden globalny obiekt singleton, który przechowuje mapę kluczy konfiguracyjnych do wartości. Ogólnie rzecz biorąc, żałuję, że tak się nie stało, ponieważ może to powodować wąskie gardła współbieżności w systemie i jest niechlujne do testów jednostkowych itp.

Myślę, że Reed Copsey ma do tego prawo( głosowałem na niego), ale zdecydowanie polecam przeczytanie wspaniałego artykułu Martina Fowlera na temat zależności iniekcja: {]}

Http://martinfowler.com/articles/injection.html

Mały dodatek też...jeśli chcesz wykonać test jednostkowy typu obiektowego, wstrzyknięcie zależności jest zdecydowanie dobrym rozwiązaniem.

 18
Author: Brent Writes Code,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-08-22 01:32:36

Co ty na to? Definiujesz interfejs Konfigurowalny za pomocą jednej metody configure (konfiguracja). Argument configuration jest po prostu hashtable, który kojarzy nazwy parametrów konfiguracyjnych z ich wartościami.

Obiekty Root mogą tworzyć hashtable konfiguracji w dowolny sposób (np. odczyt z pliku konfiguracyjnego). Ta hashtable może zawierać parametry konfiguracyjne dla głównego obiektu iselft, plus dowolny parametr, który jeden z jego komponentów, pod-komponentów, mogą być użyte podkategorie (etc).

Główny obiekt wywołuje configure (configuration) na wszystkich swoich konfigurowalnych komponentach.

 4
Author: Alain Désilets,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-10 12:45:38