Куда вы помещаете данные своего словаря?

Это не поможет вам, но это зависит...

- Что вы собираетесь делать с этими странами?

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

- Собираетесь ли вы перевести названия стран на несколько языков?

-Будет ли бизнес-логика вашего приложения зависеть от выбранной страны? -Вам нужен кантри-класс?

так далее...

Без дополнительной информации я бы начал с Enum с несколькими странами и рефакторингом в зависимости от моих потребностей...

В некоторых приложениях, над которыми я работал, в базе данных была единственная таблица Enum, содержащая все данные этого типа. Он просто состоял из двух столбцов: EnumName и Value и заполнялся следующим образом:

• "Страна", "Германия"
• «Страна», «Великобритания»
• «Страна», «США».
• «Фруктовый», «Яблочный».
• «Фруктовый», «Банановый»
• «Фруктовый», «Апельсиновый»

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

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

Если оно не будет меняться очень часто и вы можете позволить себе отключить приложение для применения обновлений, я бы поместил его в перечисление Java и написал свои собственные методы для findById(), findByName() и так далее.

Преимущества:

• Быстро - нет доступа к БД для инвариантных данных (или требования кэширования);
• Простой;
• Хорошо работает с инструментами рефакторинга.

Недостатки:

• Нужно сбить приложение для обновления.

Если вы поместите данные в собственный jar-файл, обновление будет таким же простым, как обновление jar-файла и перезапуск приложения.

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

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

Лично я всегда придерживался подхода, основанного на базе данных, в основном потому, что я уже храню другую информацию в базе данных, поэтому написать еще один DAO несложно.

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

У меня, вероятно, был бы текстовый файл, встроенный в мою банку. Я бы загрузил его в память при запуске (или при первом использовании). В этот момент:

• Это легко изменить (даже тем, у кого нет знаний в области программирования)
• Легко обновить даже без полного повторного развертывания — поместите только текстовый файл где-нибудь в пути к классу.
• Не требуется доступ к базе данных

РЕДАКТИРОВАТЬ: Хорошо, если вам нужно обратиться к данным конкретной страны из кода, то либо:

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

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

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

Я также не стал бы пытаться создавать общую таблицу перечислений, как увидел-лау >предложено, главным образом потому, что вы теряете чистые ограничения внешнего ключа, что является основным преимуществом их наличия в БД в первую очередь (можно было бы вставить их в текстовый файл). Базы данных хорошо справляются с большим количеством таблиц. Добавьте префикс «ENUM_» к именам таблиц, если вы хотите их каким-то образом отличить.

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

РЕДАКТИРОВАТЬ: Из комментариев: «Конечно, я буду использовать ограничения внешнего ключа в своей БД. Но это можно сделать с использованием или без использования перечислений на стороне приложения»

Ах, я пропустил этот момент, читая второй пункт вашего вопроса. Однако я все же считаю, что лучше загружать их на карту, в основном на основе DRY. В противном случае, когда тот, кто должен его поддерживать, доберется до добавления новой страны, он обязательно обновится в одном месте, а не в другом, и будет ломать голову, пока не поймет, что ему нужно обновить его в двух разных местах. Пример преждевременной оптимизации. ИМХО, выигрыш в производительности будет минимальным за счет менее поддерживаемого кода.

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