Зависят ли параметры внедрения зависимостей от пользовательских настроек?

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

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


dependency-injection configuration
person driis    schedule 24.05.2009    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Что касается настроек пользовательского интерфейса, я думаю, что разработчики должны сделать большую часть выбора, но оставить некоторое пространство для настройки. У меня сейчас нет ссылки, но есть интересная история одного магазина, в котором продавали варенье. Они позволяли покупателям пробовать джем с тостами, что значительно увеличивало продажи (поскольку покупатели знали качество того, что они покупают). В начале у них было не так много вариантов варенья (всего 3), и это имело успех. Когда вариантов было слишком много (например, 20), они заметили, что клиенты немного сбиты с толку таким количеством вариантов.

Еще одна причина снижения конфигурируемости — сокращение времени разработки. Если вы читали книгу Gettingreal.37signals.com/">Gettingreal.37signals.com/">Gettingreal.37signals.com/">Gettingreal.37signals.com/" (рекомендую эту) (рекомендую эту), там написано, что нужно много времени, чтобы построить меньше . В главе 10 говорится:

* Less software is easier to manage.
* Less software reduces your codebase and that means
* Less maintenance busywork (and a happier staff).
* Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code. Less software results in fewer bugs.
* Less software means less support.

Итак, ИМХО, попытайтесь выяснить, какие настройки пользователи хотели бы изменить больше всего, и сделать их настраиваемыми. Кроме того, если ваша система уже находится в производстве и продолжает медленно расти, я думаю, вы могли бы освободить больше места для конфигурации с течением времени. В Gmail, например, было не так много параметров конфигурации, но по мере того, как пользователи привыкали к этому инструменту, они начали создавать параметры для пользователей, такие как изменение тем и другие функции лабораторий Google. Таким образом, кривая обучения «не вредит» пользователям :).

Надеюсь, я помог.

person Samuel Carrijo    schedule 26.05.2009

arrow_upward
2
arrow_downward

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

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

person markusk    schedule 24.05.2009