Как динамически настроить приложение? - PullRequest
4 голосов
/ 28 января 2009

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

Где сохранить эти значения? База данных? XML-файл? Плоский файл?

Ответы [ 6 ]

3 голосов
/ 28 января 2009

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

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

1 голос
/ 28 января 2009

Я использую INI-файлы для потенциально настраиваемых пользователем файлов и BIN-файлы для данных, которые сохраняют состояние сеанса между запусками.

Но это очень зависит от того, какой тип приложения вы разрабатываете.

0 голосов
/ 01 марта 2009

Я предпочитаю простоту плоского ini файла. Вот пример Setting класс , который может оказаться полезным.

0 голосов
/ 29 января 2009

Независимо от приложения, у вас, вероятно, будет как минимум 3 источника данных конфигурации:

  1. Флаги командной строки, обычно для начальной загрузки среды выполнения, например, для поиска файлов конфигурации, установки флагов отладки, включая пути, пути классов и т. Д.
  2. Конфигурационные файлы, потенциально более одного, которые могут перекрывать друг друга. Обычно они загружают ваше приложение: строки подключения, настройки кэша, специфичные для сборки настройки и т. Д.
  3. Контроль данных в базе данных. Такие вещи, как часовые пояса, коэффициенты конверсии, стабильные отображаемые значения и т. Д. Эти данные также должны иметь версии в базе данных (например, в поле «Версия данных», а не в системе контроля версий). Управление версиями избавит вас от головной боли, когда вы обнаружите, что вам нужно изменить настройку для новой версии, но старая версия сломается, если вы ее измените.

Как правило, все, что изменяется во время выполнения, должно помещаться в базу данных. Все, что чувствительно и редко изменяется, должно входить в конфигурационные файлы, и любые взломы должны идти в командной строке (- [no] enable-bug-287438-hack может быть очень полезен, когда вам это нужно).

0 голосов
/ 28 января 2009

Обычно я использую файлы Ini или XML, если данные структурированы.

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

Я почти никогда не использую двоичные данные, если вы не хотите запутывать данные для пользователя.

0 голосов
/ 28 января 2009

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

...