Какие части приложения вы предпочитаете использовать как конфигурацию и почему? - PullRequest
1 голос
/ 25 сентября 2008

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

  1. он может и должен быть изменен не разработчиком, но не так часто, чтобы быть включенным в параметры приложения, определенные в пользовательском интерфейсе (учетные данные БД, URL-адреса служб и т. Д.)
  2. не требует языка программирования и выглядит неестественно кодируемым (локализация)

Вам есть что добавить?

Это немного связано с этим вопросом о пружине cfg . Конфигурация Spring кажется мне менее очевидным примером, потому что в моей практике она никогда не модифицируется никем, кроме разработчика. И путь извлечения может увести вас далеко, чтобы весь проект был «сконфигурирован», а не закодирован - так, где остановиться?

Поэтому, пожалуйста, опубликуйте здесь несколько примеров из вашего опыта, когда вы получили выгоду от того, что что-то сконфигурировано, а не закодировано - как конфигурация внедрения зависимостей весной и т. Д. А если вы используете spring - как часто меняется конфигурация без перекомпиляции?

Ответы [ 11 ]

5 голосов
/ 25 сентября 2008

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

Примеры включают в себя:

  • Строки подключения к базе данных
  • URL-адреса для веб-служб или служб WCF
  • Конфигурация регистрации
3 голосов
/ 25 сентября 2008

Любая информация, используемая вашим приложением, которая является «данными» и может изменяться в зависимости от того, где она установлена. Вещи как:

  • почтовый сервер smtp, используемый для отправки электронной почты
  • Строки подключения к базе данных
  • Пути к расположению файлов / папкам, используемым приложением
  • FTP-серверы и информация о подключении
  • Серверы Active Directory, используемые для аутентификации
  • Любые ссылки, отображаемые в приложении на внешнюю информацию источники
  • Предельные значения предупреждений
  • Я даже поставил фильтры RegEx, используемые для ограничения допустимых символов для полей ввода данных.
2 голосов
/ 25 сентября 2008

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

Затем вы должны определить правила для «файла конфигурации», который в конечном итоге будет не менее, чем программированием на DSL, а не на языке общего назначения. Преимущества в том, что он ближе к домену, поэтому он проще и удобнее в обслуживании, и вы можете легко изменять вещи, которые в противном случае потребовали бы новой сборки.

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

1 голос
/ 14 мая 2009

Я собираюсь использовать Spring JDBC или vanilla JDBC для сохранения данных, здесь мы решили вывести весь SQL из кода Java, поэтому он может быть лучше управляемым с точки зрения настройки и оптимизации SQL-запросов, нам не нужно нарушать код Java.

1 голос
/ 01 декабря 2008

Я использую Spring, чтобы связать все bean-компоненты в приложении J2SE без GUI (транзакционный переключатель). Таким образом, мне очень легко иметь разные конфигурации в каждом развертывании (у нас это работает в разных странах), без необходимости кодировать что-то другое. Еще одна вещь, которая мне нравится иметь, - это управлять всеми операторами SQL отдельно от кода, когда я использую простой JDBC (или Spring JDBC). Как в файле свойств, XML или как-то еще, иногда даже в качестве свойств String в bean-компонентах, которые будут использовать оператор (когда есть только один bean-компонент, который будет использовать оператор, такой как DAO).

1 голос
/ 29 ноября 2008

В приложениях Spring я на самом деле различаю два типа конфигурации:

  1. Элементы, выводимые в файлы свойств, которые относятся к «времени развертывания» или «зависят от среды»: IP-адреса / адреса сервера, расположение файловой системы и т. Д. И т. Д.

  2. Конфигурация Spring XML, которая может делать много вещей, например указывать общую структуру приложения, применять поведение через AOP и т. Д.

1 голос
/ 25 сентября 2008

Я бы также добавил ключи шифрования (которые сами должны быть зашифрованы) ...

Практическое правило - это информация, в которой нуждается приложение ПЕРЕД регулярной, функциональной работой, данными, которые ДОЛЖНЫ иметь под рукой (то есть локальные и не сетевые). Обратите внимание, что эти данные не должны динамически изменяться или их большие объемы, в противном случае они должны находиться в базе данных.

1 голос
/ 25 сентября 2008

Конфигурационные файлы должны включать:

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

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

1 голос
/ 25 сентября 2008

электронные письма / имена сотрудников, поскольку сотрудники могут приходить и уходить ... (хотя вы, как правило, должны стараться не пускать их в приложение)

1 голос
/ 25 сентября 2008

Я согласен с вашими двумя условиями, поэтому я:

  1. Редко включайте файл конфигурации как часть приложения Windows или Windows Mobile (веб-приложения - да).
  2. Если бы я включил файл конфигурации, предназначенный для настройки конечными пользователями, это определенно не был бы XML.
...