しばらく前に同様の質問がありましたが、IoC / DIのトピック全体と、私が達成しようとしていたことについての理解がはるかに少ないので、ここでもう一度説明します。
社内で一般的に使用するライブラリを構築しています。パブリックAPIの最も一般的に使用される部分は、すでにIoCに対応していますが、下位レベルの領域では、まだかなりの新機能が進行中であり、これを削除したいと思います（ただし、現時点では、実際よりも正式な理由でより多く使用されています）必要性）。
これ自体は簡単に実行できますが、もちろん、ライブラリを使用するたびに、すべてのコンポーネントを再度配線する必要があります。これはほとんど常に同じように見えるので、私は通常、これらのデフォルトの登録をAutofacモジュールにラップして、それで完了します。
（質問1：このモジュールはメインライブラリアセンブリに含まれるのでしょうか、それともAutofacがライブラリで使用される唯一のIoCコンテナである可能性が高い場合でも、スタンドアロンパッケージである必要がありますか？）
問題は、私が現在、IoCの目的を実際に理解している、またはIoCコンテナがどのように使用されているかは言うまでもなく、IoCコンテナが何をするのかを知っている唯一の開発者であるということです。そして、他のすべての人にそれらを伝えるのは悪い考えです。 Autofacパッケージを使用するか、貧乏人のDIを使用して12以上のオブジェクトのグラフを手動で作成することができます。（私はみんなを知っています-私はとにかく私の多くの小さなクラスすべてに夢中なので、彼らはそれを放っておいて、彼らが必要なものを自分で構築するでしょう。）
これを解決するために私が考えたのは、一般的に必要なタイプ（Autofacモジュールによって配線されたものと同じように見える）の事前構成されたオブジェクトをプルするService Locatorのようなものを追加することです。おそらく、軽量のIoCコンテナーによって内部的に配線されます。 。
Service Locatorはアンチパターンであり、どのような問題が発生するかを知っています。これをオブジェクト構成の（私の）手段として使用することは決してありませんが、IoC/SOLID障害の「ショートカット」としては実行可能でしょうか。 ？他にどのようなオプションがありますか？その場合、ライブラリにAutofacモジュールを含めて、「サービスロケーター」をそのフロントエンドとして機能させることも意味がありますか？