Чи варто використовувати конфігураційний файл або базу даних для зберігання бізнес-правил?

Я нещодавно читав Прагматичного програміста, який говорить, що:

Деталі псують наш незайманий код - особливо якщо вони часто змінюються. Кожен раз, коли нам доводиться заходити і змінювати код, щоб вносити певні зміни в бізнес-логіку, або в закон, або в особисті смаки управління, ми ризикуємо порушити систему - ввести нову помилку.

Полюй, Андрій; Томас, Девід (1999-10-20). Прагматичний програміст: від подорожнього до майстра (Kindle Locations 2651-2653). Пірсон Освіта (США). Kindle видання.

В даний час я програмую веб-додаток, який має деякі моделі, які мають властивості, які можуть бути лише з набору значень, наприклад (не фактичний приклад, як дані веб-додатків конфіденційні):

світло-> тип = сфера / куб / циліндр

Тип світла може бути лише трьома зазначеними вище значеннями, але відповідно до TPP, я завжди повинен кодувати так, ніби вони могли змінити і розмістити свої значення у конфігураційному файлі. Оскільки у програмі є кілька випадків цього, моє питання:

Чи варто зберігати такі значення, як ці:

• конфігураційний файл:
  'light-types' => array(sphere, cube, cylinder),
'other-type' => value,
'etc' => etc-value

• єдину таблицю в базі даних з одним рядком для кожного елемента конфігурації

• база даних з таблицею для кожного елемента конфігурації (наприклад , таблиці: light_types; стовпці: id, name)

• якимось іншим способом?

Дякую за будь-яку пропоновану допомогу та досвід.

Це ж питання виникає у більшості проектів, над якими я працюю. Зазвичай я роблю це:

1. Якщо набір можливих значень навряд чи зміниться незабаром, я використовую константи класу / інтерфейсу або перерахунки в коді та перелічені поля в базі даних. Приклад: стан публікації записів у блозі: «не опубліковано», «в режимі модерації», «опубліковано» тощо.
2. Значення, ймовірно, зміняться, але зміни не вплинуть на логіку програми - файли конфігурації. Приклад: список "як ви знайшли наш веб-сайт?" варіанти випадаючого списку в онлайн-формі закупівлі.
3. Значення, ймовірно, часто змінюються та / або мають на увазі редагуватися не розробниками, але все ж ці зміни не вплинуть на логіку - база даних або принаймні сховище ключових значень з деяким зручним інтерфейсом для редагування.
4. Зміна значень вплине на логіку - можливо, система потребує перепроектування (часто це правда) або потрібен певний механізм ділових правил. Найскладніший випадок, який я бачив досі, - це конструктор психологічних тестів, над яким працював мій колега. Кожен тип тесту може мати власну систему оцінювання, яка може відрізнятися від простого додавання до кількох шкал характеристик з позитивними та негативними значеннями або навіть людської оцінки відповідей. Після деякої дискусії щодо цього проекту, ми закінчилися з використанням Lua як сценарію, що повністю суперечить здатності не розробників створювати нові тести (хоча Lua є відносно простою мовою, ви не повинні очікувати, що непрограміст навчимось).

Про цитату ТЕС. Я думаю, що це стосується незайманого коду, але в реальному житті краще запустити простий ( принцип KISS ) і додавати функції пізніше, якщо вони справді потрібні ( YAGNI ).

Якщо ваші дані будуть знаходитися в базі даних, я рекомендую мати таблицю "light_types" у тій самій БД. Це дає вам можливість використовувати зовнішні ключі для забезпечення обмеження, що тип light-> може бути лише одним із цих значень, тому навіть якщо код псується, дані в БД завжди будуть дійсними.

Якщо дані не зберігатимуться в БД, створення одного лише для групи перерахунків не принесе багато користі. Я можу порекомендувати конфігураційний файл, якщо ви дійсно хочете уникати жорсткого кодування значень.

(Я хоч би застеріг від того, щоб занадто далеко не уникати жорсткого кодування. У будь-якій нетривіальній системі з'являться припущення щодо правил та вимог бізнесу, усвідомлюють вони це автори чи ні. Навіть якщо вам якось вдасться уникнути всіх припущення та soft-code абсолютно все, ви в основному просто закінчуєте "двигуном правил", свого роду системою всередині системи та / або мета-мовою, і у вас є маса речей на мета-мові, щоб Ви не зберегли жодної роботи та не отримали будь-якої гнучкості, вам просто довелося будувати та / або вивчати іншу мову.

Тепер, якщо ви хочете знайти і використовувати існуючий механізм правил, це може заощадити трохи роботи (разом з відповіддю на питання, де зберігати перерахунки). Але побудова власного просто вдвічі збільшує навантаження і неминуче отримує систему напівавтоматики, побудовану людьми, які насправді не знають, як зробити гідну систему управління.

Як правило, для даних слід використовувати базу даних, а для конфігурації слід використовувати конфігураційний файл. (як випливає з назви :)). Зберігання конфігурації в базі даних - це поганий розбір проблем, і це слід робити лише у випадку, коли ви маєте гарний випадок використання для її виправдання.

Існує баланс, який слід досягти, вирішуючи, яку конфігурацію використовувати. Ви повинні ставитися до своїх конфігураційних файлів стільки ж, скільки до програми, як до коду. Тримайте це якомога коротше. Це дуже просто для програм, які страждають від конфігурації, коли ви отримуєте величезний XML-файл, наповнений магічними рядками.

У випадку, який ви описуєте, було б розумно мати елемент конфігурації, щоб визначити, який файл css використовувати. (ви можете просто змінити його, якщо зміниться вимоги). Було б надмірно налаштувати стиль кожного елемента у файлі config