用户设置的依赖注入参数？

Question

大多数依赖注入框架都支持初始化注入各种参数的组件，通常从XML配置文件中读取。

这似乎是存储设置的非常方便的地方（例如服务器名称或组件需要的文件路径）。但这是正确的方法，还是有更合理的设置单独的配置文件？在您看来，用户是否应该能够通过UI更改设置是否重要？

Answer 1

我可能会将设置存储在单独的文件中，以便更清楚地说明在不同环境中可能需要修改哪些设置。这也使不熟悉依赖注入框架的人（例如，系统管理员，最终用户）更容易修改设置。

如果这是一个非常小的应用程序，并且开发人员只会更改设置，我可能会将设置保留在DI配置中。

Answer 2

恕我直言，这是常识问题。通常，我将所有内容保存在同一个配置文件中，但是在不同的部分中。例如，如果您使用过多的配置文件，那么团队中的新人将更难理解您的代码。但如果文件太大，我认为可以将它们分开。

关于UI设置，我认为开发人员应该做出大部分选择，但要为配置打开一些空间。我现在没有链接，但有一个有趣的故事，一家商店曾经卖过果酱。他们会让顾客用烤面包来品尝果酱，这会大大提高销量（因为顾客会知道他们购买的产品的质量）。在开始时，他们没有很多果酱选项（只有3个），这是成功的。当有太多选项（如20）时，他们发现客户对这么多选项感到困惑。

降低可配置性的另一个原因是缩短开发时间。如果您阅读了这本书Getting real（我推荐这本书），他们会说要花很多时间来减少建设。在第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实验室的主题和其他功能。这样，学习曲线“不会伤害”用户:)。

希望我帮助过。