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

Недавно я читал Прагматичного Программиста, который заявляет, что:

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

Охота, Андрей; Томас, Давид (1999-10-20). Прагматичный программист: от подмастерье до мастера (Kindle Locations 2651-2653). Пирсон Образование (США). Kindle Edition.

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

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

Тип освещения может быть только тремя вышеуказанными значениями, но в соответствии с 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-> type может быть только одним из этих значений, так что даже если код испортится, данные в БД всегда будут действительны.

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

(Однако я бы рекомендовал не заходить слишком далеко во избежание жесткого кодирования. В любой нетривиальной системе будут предположения о бизнес-правилах и требованиях, независимо от того, осознают это авторы или нет. Даже если вам каким-то образом удастся избежать всех предположения и софт-код абсолютно все, вы в основном просто получаете «механизм правил», своего рода систему внутри системы и / или метаязык, и у вас есть куча вещей в мета-языке для реализовать правила. Вы не сохранили работу и не приобрели гибкости, вам просто нужно было создать и / или выучить другой язык.

Теперь, если вы хотите найти и использовать существующий механизм правил, это может сэкономить вам немного времени (наряду с ответом на вопрос, где хранить перечисления). Но создание собственного просто удваивает рабочую нагрузку и неизбежно дает вам половинчатую систему, созданную людьми, которые действительно не знают, как создать достойный механизм правил.)

Как правило, база данных должна использоваться для данных, а файл конфигурации должен использоваться для конфигурации. (как подсказывает название :) ). Хранение конфигурации в базе данных - это плохое разделение проблем, и его следует выполнять только в том случае, если у вас есть хороший вариант использования для его обоснования.

При выборе размера используемой конфигурации необходимо соблюдать баланс. Вы должны относиться к своим файлам конфигурации как к части приложения, так и к коду. Держите это как можно более кратким. Для приложений очень легко пострадать от раздувания конфигурации, когда вы получите огромный XML-файл, полный волшебных строк.

В случае, если вы описываете, было бы разумно иметь элемент конфигурации, чтобы определить, какой файл CSS использовать. (Вы можете просто изменить его, если изменятся требования). Было бы излишне настраивать стиль каждого элемента в файле конфигурации