Есть параметры внедрения зависимости для пользовательских настроек? - PullRequest
2 голосов
/ 24 мая 2009

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

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

Ответы [ 2 ]

2 голосов
/ 26 мая 2009

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

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

Другая причина уменьшения возможности конфигурирования - сокращение времени разработки. Если вы прочитаете книгу Как стать реальной (я рекомендую эту), они скажут, что много времени строят меньше. В главе 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.

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

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

2 голосов
/ 24 мая 2009

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

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

...