ほとんどの依存性注入フレームワークは、注入されるコンポーネントを、通常はXML構成ファイルから読み取られたさまざまなパラメータで初期化することをサポートしています。ユーザー設定の依存性注入パラメータはありますか？
これは設定（サーバー名やコンポーネントに必要なファイルパスなど）を保存するのに非常に便利な場所のようです。しかし、適切な方法があるのでしょうか、あるいは設定のための別個の設定ファイルを持っている方が理にかなっていますか？そして、ユーザーがUIを介して設定を変更できる必要があるかどうかは、あなたの意見では重要ですか？
IMHO、これは常識の問題です。通常、私はすべて同じ設定ファイルに保存しますが、別のセクションに保存します。あまりにも多くの設定ファイルを使用すると、チーム内の新しい人があなたのコードを理解するのが難しくなります。しかし、ファイルが大きすぎる場合、私はそれを分けることが大丈夫だと思います。
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ラボのその他の機能を変更するなど、ユーザー向けのオプションを作成し始めました。このようにして、学習曲線はユーザーを傷つけません:)。
希望しました。
異なる環境でどのような設定を変更する必要があるのかを明確にするために、設定を別のファイルに保存することをお勧めします。これにより、依存性注入フレームワーク（システム管理者、エンドユーザなど）に精通していない人が設定を変更しやすくなります。
これは非常に小さなアプリケーションであり、設定は開発者によってのみ変更されるため、DI設定で設定を保持することがあります。