Какая-то устойчивость данных

Question

В основном мне нужно знать следующее:

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

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

Пожалуйста, помогите мне чувствовать себя умным

Answer 1

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

• Файлы свойств Java - если у вас есть только несколько пар ключ-значение для хранения, это самый простой способ и простой в использовании.

• Хранение XML - Если вы ищете постоянство и ищете хранилище XML, я бы рекомендовал посмотреть JAXB . Он является частью Java 6 и сделает вашу жизнь проще, чем пытаться использовать DOM.

• Постоянство базы данных - если у вас есть другие данные, которые часто меняются, вы можете также рассмотреть возможность их хранения в базе данных. JPA - отличная стандартная библиотека для этого. Это, вероятно, излишне для того, что вы ищете.

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

Answer 2

Разные методы имеют разные преимущества и недостатки:

База данных:

• позволяет использовать данные страны в запросах
• данные могут быть изменены без повторного развертывания приложения
• редактирование данных требует, чтобы вы написали какой-то интерфейс или сделали это вручную через какой-то общий браузер SQL
• требуется код доступа к базе данных и какая-то стратегия кэширования
• Любая страновая логика в коде может сломаться при изменении БД или должна быть отражена в БД

XML:

• Очень легко редактировать
• можно изменить без перекомпиляции приложения, но изменения должны быть как-то развернуты
• Требуется разбор кода и какая-то стратегия кэширования
• Любая страновая логика в коде может сломаться при изменении XML или должна быть отражена в XML

Код:

• Легко редактировать - для разработчиков
• Изменения требуют компиляции и развертывания
• Не требует дополнительных технических слоев
• Код и данные страны не могут быть синхронизированы

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

Answer 3

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

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

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

Answer 4

Я бы, конечно, не использовал их в качестве констант в коде. Имена могут меняться, в то время как страны могут создаваться, объединяться, исчезать и т. Д.

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

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

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

Answer 5

Я думаю, что «настольное решение» имеет более гибкий подход: 1. Вы можете управлять данными и связанными свойствами 2. Вы можете работать с таблицей напрямую 3. Вы можете создать связанную карту на основе таблицы БД))

Answer 6

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

Эти данные не являются статичными; название страны меняется, новое основывается, или некоторые перестают существовать.

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