Использование констант для ключей сообщений и имен таблиц базы данных и имен столбцов

Question

В последнее время во время сеанса кода с использованием констант произошли большие дебаты. Разработчиков использовали константы для следующих целей:

1. Каждого ключ сообщения, используемый в приложении I1 был объявлен как константа. Приложение содержало около 3000 ключей сообщений и, следовательно, столько же констант.
2. Каждое имя столбца базы данных было объявлено как константа. Было около 5000 названий колонок и по-прежнему считалось ...

Имеет ли смысл иметь такое огромное количество констант в любом приложении? ИМХО, здравый смысл должен преобладать. Ключи сообщений просто не должны быть объявлены как константы. У нас уже есть один уровень косвенности - зачем добавлять еще один?

Рег. имена столбцов базы данных, у меня есть смешанные мнения. Если столбец используется в нескольких классах, имеет смысл объявить его глобальной константой?

Пожалуйста, влить со своими мыслями ...

Answer 1

Если константа используется в нескольких мест икомпилятор действительно ловит проблему, да.

Answer 2

Это зависит от языка программирования, я думаю.

В PHP это не редкость, поскольку ude определяет aka contants для таких вещей, в то время как я не буду использовать это в Java или C#.

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

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

Answer 3

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

Answer 4

Если ключи сообщения I18N не определены как константы, как вы обеспечиваете согласованность? Как вы автоматически различаете опечатку и недостающее значение? Как вы проводите аудит, чтобы убедиться, что все ключи I18N выполнены в каждом новом языковом файле?

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