Kiedy używać stałych a plików konfiguracji, aby zachować konfigurację

Często walczę ze sobą, czy umieścić pewne klucze w moim pliku web.config lub w klasie Constants.cs, czy coś takiego.

Na przykład, jeśli chciałbym przechowywać klucze specyficzne dla aplikacji, bez względu na przypadek. Mógłbym je zapisać i pobrać z mojej konfiguracji internetowej za pomocą kluczy niestandardowych lub zużyć, odwołując się do stałej w mojej klasie stałych.

Kiedy chcesz używać stałych zamiast kluczy konfiguracji?

To pytanie naprawdę dotyczy każdego języka, który moim zdaniem.

Osobiście użyłbym tylko stałych jako wartości domyślnych i pozwoliłbym na ich zastąpienie wartościami z pliku konfiguracyjnego.

Jeśli aplikacja pobiera argumenty wiersza poleceń, to z kolei zastąpiłyby parametry pliku konfiguracyjnego.

Wartość w pliku konfiguracyjnym jest trudniejsza do utrzymania niż wartość w klasie stałych, ponieważ kompilator nie sprawdza, czy istnieje i jest poprawnego typu, IDE zwykle nie zapewnia pomocy dla kodu, a także dlatego, że jest to kolejna składnia, na którą musisz się przełączyć podczas programowania.

Sugerowałbym więc umieszczenie:

• Wartości, które będą takie same we wszystkich instalacjach, jak stałe w kodzie. Zaletą jest umieszczenie ich w jednej klasie stałych (możesz łatwo wypróbować różne wartości, aby zobaczyć, jak działają) i umieszczenie ich w module, który ich używa (nie musisz otwierać kolejnego pliku podczas modyfikowania tego modułu i unikanie jednego pliku, który wszyscy mogliby edytować, powodując konflikty w kontroli wersji).
• Wartości, które (mogą) wymagać zmiany dla każdej instalacji pliku konfiguracyjnego. Prawdopodobnie i tak chcesz ustawić domyślną wartość w kodzie, więc jeśli wartość nie jest ustawiona w konfiguracji, aplikacja nadal (jakoś) działa.

Zmiana stałych wymaga przebudowania aplikacji w większości przypadków. Innymi słowy, stałe pozostają stałymi, gdy ktoś nie ma dostępu do kodu.

Tak więc wszelkie informacje, które użytkownik końcowy musi podać (i musi zmienić) powinny znaleźć się w plikach konfiguracyjnych. Większość innych musi podlegać stałym wartościom. Jednak jeśli pliki konfiguracyjne są uszkodzone, muszą istnieć uzasadnione wartości domyślne lub obsługa wyjątków błędów.

Elementy, które nie są częścią abstrakcji obiektu (tj. Jeśli stałe, które nie mają być modyfikowane przez zewnętrzne (wywołujące) obiekty, są prawdopodobnie ukryte i zasadniczo oznaczają, że lepiej byłoby, gdyby były stałymi prywatnymi niż pliki konfiguracyjne.

Gdy istnieje wiele elementów konfiguracji, które dotyczą różnych obiektów, które nie są ze sobą powiązane, i gdy tak wiele obiektów musi wyciągnąć (takie same lub własne) pliki konfiguracyjne, istnieje prawdopodobieństwo, że te rzeczy powinny być stałe.

Prostą zasadą jest tworzenie stałych, gdy wiesz, że będziesz pracować ze stałym zestawem wartości, o których wiesz, że można je zastosować w dowolnym kontekście bez konieczności zmiany; zapewnić zewnętrzne konfiguracje dla wszystkiego innego.

Dobrym przykładem stałych byłoby, gdyby wszystkie kształty, z którymi pracowałeś, mogą być SQUAREalbo ROUND. W większości języków będziesz w stanie wykorzystać fakt, że wartość ta nie zmienia się w czasie, przydzielając ją tylko raz i optymalizując sposób dostępu.

Zewnętrzne konfiguracje są konieczne, gdy trzeba dynamicznie odzyskać wartość, ponieważ nie można z góry założyć wartości, z którą będziesz pracować, ale to nie znaczy, że musisz dokonać kompromisu wydajnościowego: dla wartości konfiguracji, których oczekujesz obecne, jeśli wykonane poprawnie, płacisz tylko za ich odzyskanie i nadal otrzymujesz wszystkie korzyści.

Możesz także po prostu użyć tego wzorca projektowego: „konwencja nad konfiguracją”.

http://msdn.microsoft.com/en-us/magazine/dd419655.aspx http://en.wikipedia.org/wiki/Convention_over_configuration

Stała z definicji jest miejscem w pamięci dla wartości, która nie powinna się zmieniać (np. PI).

Zakładam, że miałeś na myśli „parametr”, a nie stałą

Oprócz tego, co zostało powiedziane, należy pamiętać, że udostępnianie zmiennych danych wejściowych użytkownika z pliku konfiguracyjnego może uszkodzić aplikację.

Jeśli to możliwe, nie ujawniaj wartości w pliku konfiguracyjnym bez sprawdzenia ich poprawności w kodzie w celu sprawdzenia poprawności. Sugeruję również, aby nie umieszczać parametrów reguł biznesowych (takich jak maksymalna pensja itp.) W plikach konfiguracyjnych i nie używać stałych dla nich. Takie wartości powinny być przechowywane w bazie danych z odpowiednimi definicjami tabel, aby niektóre zabezpieczenia były egzekwowane po ich zmianie i można było automatycznie tworzyć wersje wartości danych (przy użyciu przechowywanych procs lub dzienników db). Oczywiście zależy to od wrażliwości twojej aplikacji.

Jeśli kiedykolwiek używasz plików konfiguracyjnych do przechowywania danych, pamiętaj o ich wersji.