Enum vs Config File

Question

мы хотим реализовать бизнес-логику на основе записей в таблице. У нас есть два варианта.

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

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

Каков лучший шаблон программирования для этого вопроса?

Answer 1

Почему бы не сохранить все это вместе и не поместить таблицу в базу данных, которая сообщит вам, какая таблица бизнес-записей будет следующей?

Извините, я не могу дать лучшего ответа. Мне нужно больше информации о том, что пытается сделать ваша бизнес-логика, и в каких порядках могут быть эти записи.

Answer 2

Я предпочитаю ваш первый подход. Если логика изменяется достаточно для того, чтобы потребовать изменения в вашем поле автонумерации (либо удалив старую запись, либо добавив новую), вам все равно придется изменить код, чтобы отразить новую парадигму.

Answer 3

Звучит как что-то вроде Государственного паттерна. Я предполагаю, что у вас есть таблица, в которой хранятся состояния (ID, имя) и логика, связанная с каждым из них в вашем приложении. Учитывая идентификатор состояния, учитывая логику, которую вы должны выполнить. Вы должны решить, как создать правильное состояние, если вы используете ORM, вы можете использовать дискриминатор (идентификатор состояния в этом случае).

Answer 4

Перечисления должны быть статическими и неизменными. Если у вас есть решение, которое требует замены перечисления, тогда перечисления являются неправильным решением.

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

Другой альтернативой может быть создание библиотеки ресурсов, в которой файл конфигурации является ресурсом, поэтому его нелегко изменить. Когда вам нужно внести изменения, вам нужно только скомпилировать dll ресурса и развернуть только это, а не все приложение.

Скотт Лэнгхэм упомянул использование таблицы конфигурации в вашей базе данных. Это тоже хорошая идея. Возможно ли это с вашей настройкой?