c# - DIに関する質問といくつかの問題を解決する方法

Question

私は依存性注入の初心者です。私は一度も使用したことがなく、それが何であるかを正確に理解することさえありませんでしたが、このトピックに対する最後の攻撃の後、オブジェクトとその依存関係を切り離す方法であることがわかりました。コンテナが私たちに代わってそれを行い、準備ができたオブジェクトを私たちの手に届けるようになりました。

ポイントは次のとおりです。「いつ使うべきですか？」、常に??? 実際、私は初心者で、このパターンを使用するプロジェクトを見たことがないので、ドメイン オブジェクトにどのように適用すればよいかわかりません!!! オブジェクトをインスタンス化することは二度となく、コンテナが常にインスタンス化するように思えますが、疑問が生じます...

1) たとえば、依存関係の一部が UI に由来する oobjects についてはどうですか。

public class User(String name, IValidator validator)

UI からユーザー名を取得するとしたら、conatiner はどのようにしてそれを認識し、このオブジェクトを配信するのでしょうか?

2）私が直面している他の状況があります。依存関係が既にインスタンス化されているオブジェクトである場合、たとえば... SINGLETON オブジェクトなどです。注入される依存関係の有効範囲に関する設定があるのを見ました（Spring.NETについて話している、たとえばhttpリクエストスコープ）...しかし、リクエストおよびその他のWeb関連のものは私のプレゼンテーションレイヤーにあります。デザインルールを破ることなく、プレゼンテーションレイヤーとドメインレイヤーの両方をリンクします（ドメインは、レイヤーの依存関係を持たないように、どこで消費されているかを完全に認識しない必要があるため）

皆さんからのご連絡をお待ちしております。どうもありがとう。

Answer 1

1) このコンストラクターはおそらく使用するのに適切なものではありません。バリデーターを間違った場所/方法で挿入している可能性があります。

2)Neighter ビューもモデルもコントローラーも、IoC があることを認識する必要があり、バックグラウンド アーキテクチャ (MVC コンポーネントが実際にインスタンス化される場所) にある必要があります。

アーキテクチャが複雑になり、多くの人が管理する必要がある場合は、IoC を使用する必要があります。エンタープライズ アプリケーション、またはプラグインで拡張する UI を作成している場合は、おそらくそれが必要ですが、コマンド ライン ユーティリティを作成している場合は、おそらく必要ありません。

Answer 2

次の利点のいずれかが必要な場合は常に、依存性注入を使用する必要があります。

• モジュールを簡単に交換できる機能
• アプリケーションの一部または異なるアプリケーション間でモジュールを再利用する機能
• システムのコンポーネントが抽象化に依存しているため、システムのコンポーネントを分離して並行して開発できるように、並行開発を行いたい場合
• 疎結合のため、システムのメンテナンスを容易にしたい場合
• テスタビリティ（モジュールの置き換えに特化）が欲しいとき。これは、DI を使用する最大の理由の 1 つです。

他の質問に答えるには:

1) 多くの IoC コンテナーを構成して、特定のコンストラクター パラメーターを指定し、他のパラメーターをコンテナーによって解決できるようにすることができます。ただし、バリデーターの依存関係を取り、ユーザー名を受け取り、新しいユーザーを返すメソッド (直接インスタンス化するか、コンテナーから解決するかのいずれかUserFactory) を持つほうが適切な場合があるため、そのコードのリファクタリングについて考える必要がある場合があります。 NewUser）。

2) ビルドする各アプリケーションには、コンテナーが構成されているコンポジション ルートがあり、ルート オブジェクトが解決されます。したがって、各アプリには独自の IoC 構成があるため、アプリケーションの種類と構成設定の間には予想されるリンクがあります。共通の抽象化登録は、すべてのアプリケーション間で共有できる構成コードに配置できます。

Answer 3

一般に、いったん IoC に移行すると、すべてを IoC に登録し、コンテナーが完全にハイドレートされたオブジェクトを吐き出すようにする傾向があります。ただし、いくつかの有効なポイントを取り上げます。

おそらく、「依存関係」の定義が適切です。広い意味では、依存関係とは、特定のクラスが正しく機能するために具体的な実装が必要な一連の機能 (インターフェイス) です。したがって、重要なプログラムのほとんどは依存関係に満ちています。メンテナンスを容易にするために、すべての依存関係を疎結合にすることが一般的に推奨されます。ただし、疎結合の場合でも、依存関係のインスタンス化を自動化する必要はありません。これらのオブジェクトが、IoC レジストリを汚染したくない特殊な情報を必要とする場合です。目標は、必ずしも作成ではなく、使用法を疎結合することです。

ポイント1に関して、一部のIoCフレームワークは、外部パラメーターを与えるとうまくいきません。ただし、通常はデリゲートをファクトリ メソッドとして登録できます。そのデリゲートは、UI によって外部情報が与えられる Controller のようなオブジェクトに属している場合があります。ログインは完璧な例です。LoginController などのオブジェクトを作成し、それを ILoginController として IoC に登録します。ログイン ページでそのコントローラーを参照すると、ログイン ページがインスタンス化されるときにコントローラーが挿入され、ログイン ページは入力された資格情報を渡します。その後、コントローラーは認証を実行し、ユーザー オブジェクトを生成するメソッド GetAuthenticatedUser() を持ちます。このメソッドをユーザーのファクトリーとして IoC に登録できます。ユーザーが必要になるたびに、ファクトリー デリゲートが評価されます。

ポイント 2 では、オブジェクトのインスタンスを 1 つ設定することが IoC パターンの強みです。プライベート インスタンス コンストラクター、静的インスタンス、および静的コンストラクターを使用してインスタンスを生成する真のシングルトンを作成する代わりに、クラスを IoC に登録し、一度だけインスタンス化してすべてのリクエストに対してその 1 つのインスタンスを使用するように指示するだけです。強みは柔軟性です。後で複数のインスタンスが必要な場合は、登録を変更するだけです。どちらの方法でも、デザイン パターンの規則に違反することはありません。コントローラーがすべてのページで同じであるか、リクエストごとに新しいインスタンスであるかに関係なく、ビューには常にコントローラーが挿入されます。