Шаблон проектирования наилучшей практики для определения «типов» в базе данных с потенциальными многоязычными требованиями

Question

У меня вопрос более конкретный:

Я хочу, чтобы пользователи на нескольких интерфейсах видели «Тип» строки базы данных. Скажем для простоты, что у меня есть таблица person и типы могут быть Student, Teacher, Parent и т. Д.

Конкретной программой была бы java с hibernate, однако я сомневаюсь, что это важно для вопроса, но допустим, что мои данные смоделированы в бинах Entity, а поле типа "Person" - это перечисление, которое содержит мои 3 варианта, в идеале хочу, чтобы у моего объекта Person был метод getType(), который мой интерфейс мог бы использовать для отображения типа, а также мне нужно, чтобы мой интерфейс знал потенциальные типы.

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

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

Последняя мысль: я создаю таблицу базы данных PersonTypes, в этой таблице есть номер для type_id и string, определяющий тип. Это нормально, и если установлен внешний ключ, я не могу удалить типы, которые я использую, моему внешнему интерфейсу нужно будет увидеть потенциальные типы, я думаю, что лучший способ - предоставить сервис, который будет использовать слой Hibernate, чтобы сделать это.

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

Существует ли общая схема проектирования для достижения такого поведения? Или кто-нибудь может предложить хороший способ сделать это?

С уважением,

Глен х

Answer 1

Вы можете использовать следующие практики:

1. Использовать шаблон синглтон-дизайна
2. Использовать механизм обналичивания, например EhCashe для типа кешачеловек и перезагрузите когда нужно.

Answer 2

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

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

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

Answer 3

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

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

Последний подход, который я могу придумать, - хранить строки i18n вместе с информацией о типе в PersonType. Это приемлемо для небольшого количества языков, хотя можно считать антипаттерном. Но это позволило бы вам иметь такой метод:

public String getName(PersonType type, Locale loc) {
  if (loc.equals(Locale.EN)) {
   return type.getEnglishName();
  } else if (loc.equals(Locale.DE)){
   return type.getGermanName();
  } else {
    return type.getDefaultName();
  }
}