Czy powinienem używać pliku konfiguracji lub bazy danych do przechowywania reguł biznesowych?

Niedawno czytam The Pragmatic Programmer, który stwierdza, że:

Szczegóły psują nasz nieskazitelny kod - zwłaszcza jeśli często się zmieniają. Za każdym razem, gdy musimy wejść i zmienić kod, aby uwzględnić zmiany logiki biznesowej, prawa lub osobistych upodobań kierownictwa, ryzykujemy złamaniem systemu - wprowadzeniem nowego błędu.

Hunt, Andrew; Thomas, David (1999-10-20). Pragmatyczny programista: od czeladnika do mistrza (lokalizacje Kindle 2651-2653). Pearson Education (USA). Wersja Kindle.

Obecnie programuję aplikację internetową, która ma niektóre modele, które mają właściwości, które mogą pochodzić tylko z zestawu wartości, np. (Nie rzeczywisty przykład jako poufne dane aplikacji internetowej):

światło-> typ = kula / sześcian / cylinder

Typem światła mogą być tylko powyższe trzy wartości, ale zgodnie z TPP zawsze powinienem kodować, tak jakby mogły się zmienić i umieścić swoje wartości w pliku konfiguracyjnym. Ponieważ w aplikacji jest kilka takich przypadków, moje pytanie brzmi:

Czy powinienem przechowywać ewentualnie takie wartości w:

• plik konfiguracyjny:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• pojedyncza tabela w bazie danych z jednym wierszem dla każdego elementu konfiguracji

• Baza danych z tabeli dla każdego elementu konfiguracji (np tabela: light_types; kolumny: id, name)

• w inny sposób?

Wielkie dzięki za wszelką oferowaną pomoc / wiedzę.

To samo pytanie pojawia się w większości projektów, nad którymi pracuję. Zazwyczaj robię to:

1. Jeśli zestaw możliwych wartości prawdopodobnie nie zmieni się w najbliższym czasie, używam stałych klasy / interfejsu lub wartości wyliczanych w kodzie i polach wyliczalnych w bazie danych. Przykład: stan publikacji wpisów na blogu: „niepublikowany”, „w trakcie moderacji”, „opublikowany” itp.
2. Wartości prawdopodobnie się zmienią, ale zmiany nie wpłyną na logikę programu - pliki konfiguracyjne. Przykład: lista „jak znalazłeś naszą stronę internetową?” opcje listy rozwijanej w formularzu zakupów online.
3. Wartości prawdopodobnie często się zmieniają i / lub mają być edytowane przez programistów, ale zmiany te nie wpłyną na logikę - bazę danych lub przynajmniej pamięć klucz-wartość z jakimś przyjaznym interfejsem do edycji.
4. Zmiana wartości wpłynie na logikę - prawdopodobnie system wymaga przeprojektowania (często prawda) lub potrzebny jest silnik reguł biznesowych. Najtrudniejszym przypadkiem, jaki do tej pory widziałem, był konstruktor testów psychologicznych, nad którym pracował mój kolega. Każdy typ testu może mieć swój własny system punktacji, który może różnić się od prostego dodawania do wielu skal charakterystyk z wartościami dodatnimi i ujemnymi, a nawet oceną odpowiedzi przez człowieka. Po krótkiej dyskusji na temat tego projektu, ostatecznie wykorzystaliśmy Luę jako silnik skryptowy, co jest całkowicie sprzeczne ze zdolnością osób niebędących programistami do tworzenia nowych testów (mimo że Lua jest stosunkowo prostym językiem, nie należy oczekiwać, że nie jest programistą nauczy się tego).

O wycenie z TPP. Myślę, że dotyczy to nieskazitelnego kodu, ale w prawdziwym życiu lepiej zacząć od prostej ( zasada KISS ) i dodać funkcje później, jeśli są naprawdę potrzebne ( YAGNI ).

Jeśli twoje dane będą w bazie danych, polecam mieć tabelę „light_types” w tym samym DB. Daje to możliwość użycia kluczy obcych w celu wymuszenia ograniczenia, że ​​typ light-> może być tylko jedną z tych wartości, więc nawet jeśli kod się zepsuje, dane w bazie danych zawsze będą poprawne.

Jeśli dane nie będą przechowywane w bazie danych, utworzenie jednego tylko dla grupy wyliczeń nie przyniesie wiele dobrego. Mogę polecić plik konfiguracyjny, jeśli naprawdę chcesz uniknąć twardego kodowania wartości.

(Ostrzegam jednak, aby nie posunąć się za daleko w unikaniu twardego kodowania. W każdym nietrywialnym systemie będą założenia dotyczące reguł biznesowych i wymagań, niezależnie od tego, czy autorzy zdają sobie z tego sprawę, czy nie. Nawet jeśli jakoś uda się uniknąć założenia i miękki kod absolutnie wszystko, po prostu kończy się to „silnikiem reguł”, rodzajem systemu wewnątrz systemu i / lub meta-językiem, i masz mnóstwo rzeczy w meta-języku, aby wdrożyć zasady Nie oszczędziłeś żadnej pracy ani nie zyskałeś elastyczności, musiałeś tylko zbudować i / lub nauczyć się innego języka.

Teraz, jeśli chcesz znaleźć i wykorzystać istniejący silnik zasadami, które mogą pomóc Ci zaoszczędzić trochę pracy (wraz z odpowiedzi na pytanie, gdzie przechowywać teksty stałe). Ale zbudowanie własnego podwaja obciążenie pracą i nieuchronnie daje ci na wpół ospały system zbudowany przez ludzi, którzy naprawdę nie wiedzą, jak stworzyć porządny silnik reguł).

Ogólnie rzecz biorąc, do danych należy użyć bazy danych, a do konfiguracji należy użyć pliku konfiguracyjnego. (jak sama nazwa wskazuje :) ). Przechowywanie konfiguracji w bazie danych jest złym rozdzieleniem problemów i powinno być wykonane tylko wtedy, gdy masz dobry przypadek uzasadnienia tego.

Przy podejmowaniu decyzji o ilości konfiguracji należy zachować równowagę. Powinieneś traktować swoje pliki konfiguracyjne tak samo jak część aplikacji, jak kod. Zachowaj to tak zwięzłe, jak to możliwe. Bardzo łatwo jest aplikacjom cierpieć z powodu rozlanej konfiguracji, w wyniku której powstaje ogromny plik xml pełen magicznych ciągów.

W opisywanym przypadku uzasadnione byłoby posiadanie elementu konfiguracyjnego do określania, który plik css ma być używany. (możesz to po prostu zmienić, jeśli zmienią się wymagania). Byłoby przesadą konfigurować styl każdego elementu w pliku konfiguracyjnym