Чтобы не было двоякой трактовки - "справочные данные" - это статические данные, описывающие некое свойство сущности, так называемые "словари" - например, у меня это для сущности Пользователь - страна проживания, используемые языки, валюта использования и т.д., то есть данные, внесенные в БД (или другое хранилище) заведомо имеющие ограниченную длину и не подлежащие редактированию.
"Локализованные" - на N-ном количестве языков интерфейса.
Веб-проект. Spring (framework, MVC, Security). Hibernate.
Ранее в проекта всегда не парился с этим понятием и использовал отдельные таблицы в БД. Причем, для каждого языка создавал дополнительное поле (редактировал сущность), а изымал в основном, используя либо параметризованные запросы к БД с указанием требуемого поля, либо (значительн реже) - рефлексию для объекта-сущности. Пример Location:
idisotitle_entitle_frtitle_ru1usUSAUSAСША2caCanadaCanadaКанада
Ну, а дальше ссылался на идентефикатор - таблицы связывались.
Если количество языков заведомо неизвестно (планируется добавление и даже динамическое добавление), то в таблице можно оставить только iso (если ссылаться на пример), а в файлах с локализованными метками (xxxxx_en.properties, xxxxx_fr.properties) указывать название, типа location.us=USA, location.ca=Canada и т.д. Это как бы делает гибче работу с языками.
Однако мне очень не нравится черезчур активное использование БД для таких второстепенных задач: во-первых, обеспечивая целостность, приходится постоянно "дергать" зависимые таблицы. Вроде ерунда, но иногда так получается, что изымается сущность, у нее 2 зависимых таблицы с динамическим содержанием, а с ними - до десятка справочных! И при этом использование этих второстепенных данных фактически сводится к минимуму, так как для отображения/редактирования на клиенте на этот клиент отсылаются (или заполняется шаблон - тут это неважно) все эти справочники целиком, затем объект и еще проводится некая работа на клиенте для отображения соответствия справочным данным (из нашего примеру, отобразить страну пользователя в выпадающем списке всех стран). Я надеюсь, что смысл недовольства, который я хочу донести, понятен. Логичнее было бы вместо ссылки на идентефикатор из таблицы стран просто указать "us" (уникальный указатель), передать на клиент список стран, который уже хранится (память, диск) и также отобразить. Особо ни целостность, ни некие теоретические коллизии, не интересуют в рамках рассматриваемых проектов.
Для хранения данных, которые подразумевается динамически отображать на клиенте (скажем, по ajax-запросу), удобно было бы хранить уже готовый JSON в пропертях, типа такого:
location.list=[{"key":"us","val":"USA"},{"key":"ca","val":"Canada"}]
Как мне кажется, преимуществ по скорости уйма - крайне гибкая работа с локалями, максимально эффективная работа с данными для динамического запроса с клиента, так как содержимое пропертей "висит" в памяти, берется и отсылается уже в готовом виде. Так как известно, что такие "справочники" относительно небольшие - десяток-полтора с максимальным количеством до сотни, то памяти используется мизер.
Но! Я пока не вижу явных подводных камней, но интуиция мне говорит, что где-то есть подвох и я могу разочароваться в таком механизме. Так как я явно его не вижу, то хочу спросить - существует ли "правильное" использование справочных локализованных данных при описанных условиях?
Второе - я подключаю пропертиз в конфиге Спринга как-то так:
1.
2.
3.
4.
5.
6.
<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
<property name="basename" value="classpath:messages"/>
<property name="defaultEncoding" value="UTF-8"/>
<property name="cacheSeconds" value="1"/>
<property name="fallbackToSystemLocale" value="false"/>
</bean>
Файлы пропертей загружаются Спрингом при старте проекта. Если я хочу сделать динамическое изменение данных, то как обновить их в контексте Спринга, не перегружая проект? - Думаю, вопрос несложный, и наверняка найду несложное решение, но и вопрос, в принципе, второстепенный.
Из собственного опыта, какую вы используете архитектуру для работы со справочными данными?
