.NET Coreクラスライブラリは独自の実装を登録する必要がありますか？
私たちのチームは最近、.NET CoreクラスライブラリがAddMyServices（）のようなIServiceCollection拡張メソッドを提供するという事実によって、独自の実装を登録することが良い方法であるかどうかを決定するのに大きな苦労をしました。
私のポイントは、次の理由でこれを行うのが良いことでした。
- トップレベルのアプリケーションは、使用する基本的なライブラリの詳細をすべて知っている必要はありません。
- トップレベルのアプリケーション（通常はスタートアップクラス）は、その実装の登録に必要なすべての名前空間への参照で汚染されていません。
- トップレベルのアプリケーションが、参照されたライブラリで定義されたいくつかのインターフェースの独自のカスタム実装を提供したい場合でも、それを行うことができます。 .NET Core依存性注入により、複数の登録が可能になります。
- このクラスライブラリを参照しているアプリケーションが他にある場合は、ブロックをコピーして貼り付ける必要はありません。各アプリケーションにAddTransient行。
反論は次のとおりでした：
- 一部のサンプルアプリケーションでは、すべての実装を最上位のStartupメソッドに登録するアプローチを使用しています。
- 上記のアプローチは機能にのみ使用されます（ただし、機能と呼ばれるものと呼ばれないものについて意味的な疑問が生じます）。それでもクラスライブラリは、実装する機能に名前を付け、IServiceCollection拡張クラスに個別のAddFeatureXYZ（）メソッドを提供できます。
- 提供される可能性のあるすべての実装を登録するAddService（）拡張メソッドを使用すると、DIコンテナーのパフォーマンスに影響を与える可能性があります。これは、特定のクラスライブラリが多くの実装を提供するが、使用される実装が少ない場合に意味があります。しかし、開発者はAddServices（）を呼び出すかどうかの自由をまだ持っています。
もっと経験豊富な.NET Core開発者に、すべてのプロとのアプローチについて尋ねたかったのですが、おそらく私はそれが欠けています。ここに記載しなかった2番目のアプローチを使用することについて強力な議論がある場合、私はそれについてよく知りたいと思います。
PS。この質問は、より意見に基づくものとしてマークされたため、StackOverflowから移動されました。私の意見では、それはオブジェクト指向プログラミングのコア原則に触れており、問題は、大多数の開発者が選択しているものを見つけることではなく、なぜ誰かが一方に対して他方を好むかについてです。
ありがとう、Radek
ASP.Netコアドキュメントで推奨
各services.Add {SERVICE_NAME}拡張メソッドは、サービスを追加（場合によっては構成）します。たとえば、services.AddMvc（）は、RazorページとMVCが必要とするサービスを追加します。 アプリはこの規則に従うことをお勧めします。 Microsoft.Extensions.DependencyInjection名前空間に拡張メソッドを配置して、サービス登録のグループをカプセル化します。
しかし、私はしません。
プラグインの設定に関して最も厄介なことの1つは、プラグインの設定に使用する拡張メソッドを推測しようとすることです。あるいは、名前とバージョンとフレームワークの間で変更されているように見えるので、それらのバージョンは
第二に、多くの場合、これらのロールアップされた登録メソッドは、基盤となるサービスでオーバーライドまたは構成する必要のあるすべてのものを公開しません。サービスマネージャーの要点は、必要に応じて依存関係を置き換えることができるようにすることですが、それを行う拡張メソッドはそれを防ぐことができます。
しかし、おそらく最も重要なこととして、この条約がまだ成立していないと思います。 startup.csとprogram.csに関しては、いくつかの競合する哲学があるようです。 1つの方法しかサポートしていない場合、誰かの反対側にいることになります。
拡張メソッドを提供しますが、別のオプションパッケージで提供します。ユーザーが必要に応じてコンポーネントを手動で登録したり、デフォルトのセットアップで拡張メソッドを使用したりできるようにします。