ASP.NET Core DI抽象化の何が問題になっていますか？

数か月前、ASP.NET CoreがまだRC1にあったときに、テストプロジェクトをMVC 5からASP.NET Coreに移行する最初の厄介な試みをしました。 当時、プロジェクトではすでにSimple InjectorのIOCライブラリを使用していたため、rc1でサポートされていたため、このライブラリを引き続き使用したいと考えました。 このライブラリの新しいバージョンのリリースをフォローしましたが、比較的最近、テーマ別ブログSimple Injectorに投稿されたかなり興味深い記事に出会いました。 この記事は適切なライブラリに依存していますが、その主な価値は、より一般的な問題-ASP.NET Coreの新しいDI抽象化を提起することです。



Simple InjectorライブラリのIOC 記事

投稿者Steve

翻訳の誤りや不正確さを指摘していただければ幸いです。



過去数年間、Microsoftはプラットフォームの新しいバージョンを開発してきました。 NET：.NET Core .NET Coreは、既存の.NETプラットフォームの完全な再設計であり、真のクロスプラットフォーム互換性とクラウドテクノロジーとの互換性を目指しています。 .NET Coreの開発を厳密に追跡し、RC1以降、プラットフォーム互換バージョンのSimple Injectorをリリースしました。 Simple Injector v3.2のリリースでは、.NET Coreを公式にサポートしています。



お気づきかもしれませんが、Microsoftはフレームワークのコアコンポーネントの1つとして独自のDIライブラリを追加しました。 誰かが「ついに！」と叫ぶかもしれません。 このようなコンポーネントが存在しないため、.NETの多くのオープンソースDIライブラリが発生しました。 そして、Simple Injectorは明らかにそれらの1つです。



誤解しないでください。Microsoftが.NETの主なプラクティスとしてDIを推進していることに感謝しています。これにより、DIを実践するさらに多くの開発者が登場し、業界にプラスの影響を与える可能性があります。 ただし、問題は、Microsoftが組み込みのDIコンテナの上に定義した抽象化から始まります。 以前のResolve抽象化（ IDependencyResolverおよびIServiceProvider ）と比較して、新しい抽象化はIServiceCollectionの上にRegister APIを追加します 。 このMicrosoftの抽象化の本質は、他の（より機能が豊富な）DIライブラリがプラットフォームに接続でき、アプリケーション、サードパーティツール、およびフレームワークの開発者が標準化された抽象化を使用して依存関係を登録することです。 これにより、アプリケーション開発者は、選択したDIライブラリを統合するための標準を取得できます。



一見すると、そのような抽象化を持つことは良い考えのように思えるかもしれません。 一般的に言えば、ソフトウェア業界には（追加の）抽象化レベルを追加しても解決できない問題はほとんどありません。 この場合、Microsoftの推論は誤りです。 DIの専門家は、最初からこの問題について警告していましたが、役に立ちませんでした。 マーク・シーマンは、 ここでこのアプローチの問題をかなり正確に説明しましたが、私の意見では、次の重要な点を強調することができます：

• このアプローチは、最小公約数に向かって引きます。
• このアプローチはイノベーションを抑制します
• このアプローチはバージョニング地獄を追加します
• DIコンテナを使用しないと作業が難しくなります
• アダプターの開発がオープンソースコミュニティのメンバーによって処理される場合、これらのアダプターは異なるレベルの品質を持ち、 Conforming Containerの最新バージョンと互換性がない可能性があります（約。 ここで説明するテンプレートを参照）

これらは、.NET Coreの新しいDI抽象化で今日直面する真の課題です。 DIコンテナは、 登録APIに関して非常にユニークで互換性のない機能を備えていることがよくあります 。 たとえば、Simple Injectorは、多数の構成エラーを検出するために非常に慎重に設計されています。 最も顕著な例の1つ（さらに多くの例があります）は、彼の診断能力です。 これは、DI抽象化のユーザーが持つ期待と基本的に互換性のない機能の1つです。 しかし、ユーザーは新しい抽象化に何を期待しますか？



DI抽象化ユーザーは、3つのグループに分類できます。フレームワークの開発者、外部ライブラリ、およびアプリケーション自体。 特にフレームワークと外部ライブラリの開発者は、一般的な抽象化を通じて依存関係の登録を追加しようと考えています。 これら2つの開発者グループでは、使用可能なすべてのアダプターでコードを検証することはほぼ不可能であるため、組み込みコンテナーを使用してコードをテストします。 そして、これらの開発者はビルトインコンテナを使用しますが、どのアダプタを使用しても、ビルトインコンテナから標準的な動作を暗黙的に期待します（おそらくそうすべきです）。 つまり、このインラインコンテナは、コントラクトと抽象化の両方の動作を定義します。 作成される各アダプターは、組み込みコンテナーの正確なスーパーセットでなければなりません。 標準からの逸脱は許可されません。これにより、組み込みコンテナのデフォルトの動作に依存する外部ライブラリの操作が中断されるためです。



Simple Injectorの診断と検証は、開発の生産性を大幅に向上させる多くの機能の1つです。 他のDIライブラリを使用した場合、開発プロセスのずっと後に発見される可能性のある問題を見つけることができます。 ただし、診断とアプリケーション、およびサードパーティコンポーネントを実行すると問題が発生します。サードパーティコンポーネントがSimple Injector診断で自動的に「ルールに従って」動作することはほとんどありません。 標準のコンテナを使用した特別な場合に登録を（うまく行えば）テストしたとしても、Simple Injectorが疑わしいと見なすような方法で依存関係を登録する可能性があります。 Simple Injectorの仮想アダプターがサードパーティの依存関係とアプリケーションの依存関係の登録を区別することは不可能です。 診断を無効にすると、最も重要な安全メカニズムの1つが完全に削除されますが、診断を保存すると、サードパーティコンポーネントからの誤検出が発生し、これらの誤検出はアプリケーション開発者によって抑制される必要があります。 サードパーティのコンポーネントの登録はほとんどアプリケーション開発者から隠されているため、これらすべての問題に取り組むことは難しく、イライラさせられ、時には不可能になることさえあります。 それは議論することができます-まあ、シンプルインジェクターはサードパーティのツールで問題を見つけます。 しかし、サードパーティライブラリの開発者に連絡して「問題」を説明しようとすると、「互換性のない」アダプタを開発したことは「明らか」なので、彼らはおそらく私たちに矢を向けます。



Simple Injectorの診断機能は、.NET Core DI抽象化用のアダプターを作成するときに遭遇した多くの非互換性の1つです。 その他の非互換性：

• Simple Injector がコレクション登録を1対1の表示から明示的に分離する方法
• Simple Injectorがオープンジェネリック登録を処理する方法。

Simple Injectorと完全に互換性のあるアダプターを作成するには、フレームワークの多くの有名な機能を削除する必要があります。これにより、ライブラリーの既存の動作が変更され、開発の指針となった原則に違反するものに変わります。 魅力のないソリューション。 互換性を損なう変更につながるだけでなく、Simple Injectorと開発者がそれを気に入っていた機能と動作も消えます。 この意味で、 Markが説明したように、アダプターを持つことは「息苦しいイノベーション」です。 Simple Injectorでは多くの革新を行っており、アダプターによりSimple Injectorはユーザーにとって実質的に役に立たなくなります。 また、アダプターにより、さらなる改善や革新を行うことができなくなります。 Simple Injectorの哲学を過激だと考える人もいるかもしれませんが、私たちは違った考え方をしています。 ユーザーに最も適していると考えられる方法で設計しました。 また、 NuGetパッケージのダウンロード数は、多くの開発者が同意していることを示しています。 特定のアダプターに準拠していると、ユーザーのニーズをさらに満たすことができなくなります。



Simple Injectorのビジョンは他のほとんどのコンテナよりも標準から逸脱する可能性がありますが、将来のDIライブラリの一般的な抽象化の定義そのものは、将来のライブラリの「イノベーションを抑制する」という、より急進的または革新的な視点です。 Simple Injectorが提供するのと同じチェックを導入する他のコンテナの1つを想像してください。 このような機能は、DI抽象化の契約に違反しない限り導入できません。 そのようなアダプターを持っているという単なる事実は、私たちの業界の進歩を妨げる可能性があります。



この説明で、Microsoft DI抽象化は「最低公約数」ではないことも明らかにしたいと思います。「最低公分母」はすべてのDIライブラリとの互換性を意味するからです。 ここで述べたように、既存のDIライブラリはどれもこの抽象化と完全に互換性がない可能性があります。 部分的に、これは、組み込みコンテナーが抽象化コントラクトを定義しているにもかかわらず、この抽象化のテストを含むプロジェクトには、すべてのシナリオで正確な動作を完全に決定するかなりの数のテストケースがないという事実に要約されます。 これまで、すべてのアダプター実装は、アダプター実装が組み込みコンテナーの動作とほぼ同期していることを推測し、最善を期待する試みでした。 たとえば、Autofac開発者は、かなり深刻な互換性の問題があることに気づき 、最終的には 私たち と同じ結論に達しました 。



Microsoft DIライブラリに機能が豊富で、Simple Injectorの検証や診断などの機能が含まれていれば、それほど悪くはありません。 次に、すべての機能を備えた同じDIライブラリを使用できます。 残念ながら、実装はそれほど機能が豊富というわけではなく、Microsoft自身は実装を次のように説明しました。



最小限のDIコンテナ、追加の注入機能が必要ない場合に便利



さらに悪いことに、インラインコンテナは抽象化コントラクトを定義するため、インラインコンテナに新しい機能を追加すると、既存のすべてのアダプターが破損します。 抽象化を使用するサードパーティの開発者は、組み込みライブラリ（.NET CoreのDI）を使用して（彼のライブラリ）のみをテストします。 また、サードパーティの開発者のライブラリが、アダプタでまだサポートされていない組み込みコンテナに追加された機能に依存し始めると、何かが壊れてアプリケーション開発者が苦しむことになります。 これは、 Mark Seemannが彼のブログで議論しているバージョン管理の地獄の一側面です。 少なくともMicrosoftが変更を加えるたびにメジャーバージョン番号を増やすことを願っています。 現在の実装が「ミニマル」であるだけでなく、完全に使用可能な多機能DIコンテナーに発展することは決してありません。なぜなら、それらは追い詰められているからです。将来のすべての変更は互換性を壊す変更であり、誰もが悪くなります。



最善の解決策は、抽象化とそのアダプターの使用を完全に避けることです。 Mark Seemannが こことここで非常に正確に説明したように 、ライブラリとフレームワークはDIコンテナをまったく使用する必要がないかもしれません。 残念ながら、抽象化を定義するという事実が、抽象化の使用を避けることをはるかに難しくしています。 抽象化を定義し、その使用を積極的に推進することにより、Microsoftはライブラリおよびフレームワークの数千のサードパーティ開発者を導き、ライブラリおよびフレームワークの適切な抽象化の定義について考えることをやめさせます（ Mark Seemannの記事はこれを明確に説明しています） マイクロソフトは、世界全体が1つの共通の抽象化を必要としているとMicrosoftに信じさせるため、開発者はもはやそれについて考えません。 MVCの新しいファクトリインターフェースが非常に遅い時期に登場することはすでに見ました（たとえば、RC2より前のIViewComponentActivator抽象化として）。 そして、MVCチームがこのようなエラーを開発サイクルのこのような後期段階にもたらすことがわかった場合、新しい.NETプラットフォームで開発を開始するすべての開発者に何を期待できますか？

おわりに

DI抽象化を定義することは、今後数年間私たちを悩ませるMicrosoftの痛ましい間違いです。 それはすでに革新を抑制し、バージョン管理の地獄を生み出し、多くの開発者を混乱させます。 抽象化は多くのDIライブラリと互換性がなく、専門家の推奨に反して、Microsoftは世界を互換性のないコンテナと部分的に互換性のあるコンテナに分割することでそれを維持することを決定しました。これにより、DI抽象化を実装するアダプタとこの抽象化を使用するサードパーティライブラリに関する問題の無限の報告につながります。



アプリケーション開発者としての私たちの意見では、アダプターの使用は控えるべきです。 次の記事では、これにアプローチする方法と、互換性のないコンテナーがなくても、これが信頼できる方法である理由について詳しく説明します。



連絡を取り合いましょう。