1

IoC の基本的な概念は理解できますが、最初の概念を超えて視野を広げるのに苦労しています。

基本的に、DI フレームワークを使用する場合、依存関係のあるオブジェクトに new キーワードを使用しないでください。これは、DI フレームワークの解決メソッドを呼び出さないため、解決のチェーンをトリガーしないためです。

ユーザーが必要とするオブジェクト A を必要とするオブジェクト B を必要とするオブジェクト C を必要とするオブジェクト ...

DI フレームワークを使用すると、それが起こります。しかし、 new キーワードを使用すると、次のようになります。

オブジェクト A をインスタンス化するだけです

質問 1: 私は正しいですか? 違う ？それとも「場合による」ということですか？

Mark Seemann ( https://stackoverflow.com/a/2490797/2671072 ) の回答を読んだところ、彼は次のように述べています。

DI コンテナーは、アプリケーションのコンポジション ルート内の依存関係グラフ全体を解決し、邪魔にならないようにする必要があります。

質問 2 : 彼は、DI フレームワークを (何かを解決するために) 呼び出す必要があるのは、アプリケーションの開始時だけであり、そこからは何も問題なく、そのままにしておかなければならないことを暗示しているのでしょうか?

私はプロジェクトに取り組んでいます。しかし、インターフェイスとクラス (エンティティ、値オブジェクト、実装) がどこに行くべきか (アセンブリ、名前空間の命名など) を定義するのに苦労しています。

質問 3: DI は、コード編成のための特別な構造を暗示していますか?

ドメイン/ビジネス レイヤーは DI フレームワークを参照すべきではないと聞きました。

質問 4: その推奨事項は他のレイヤーにも適用されますか? それとも偽ですか？

私は 2 つのライブラリ (LibraryA と LibraryB など) を使用しています。LibraryB には、ClassA、ClassB、ClassC の 3 つのクラスが含まれています。各クラスは前のものに依存します (ClassA はルート/集合体です)。LibraryA は ClassA に依存します。

質問 5 : ライブラリ B 内にファクトリを作成し、ClassA とその依存関係 (new キーワードのみを使用) を作成することに専念する方が良いですか、それとも DI フレームワークをフルに活用して、手動で ClassA、ClassB、ClassC を登録する方が良いでしょうか? ClassA を解決しますか？

4

2 に答える 2

4

新しいキーワードはもう使用しないでください

newables と injectables の違いがすべてです。はい、引き続き new キーワードを絶対に使用する必要がありますが、services/injectables には使用しないでください。

彼は、DI フレームワークを (何かを解決するために) 呼び出す必要があるのは、アプリケーションの開始時のみであることを暗示していますか?

リクエストごとに 1回解決する必要があります。アプリケーションが 1 つの要求を処理して停止した場合 (たとえば、コンソール アプリケーション)、これは起動時に 1 回解決することを意味します。ただし、ほとんどのアプリケーション タイプ (Web アプリケーション、Web サービス、デスクトップ アプリケーションなど) は、多くの要求を (場合によっては同時に) 処理します。これは、多くの「ルート」オブジェクトが解決されることを意味します。

リクエストごとに解決を行うことが重要です (そのアプリケーションのコンテキストでの「リクエスト」が何であれ)。これは、完全なアプリ ドメインに対して 1 つの解決を行うと、1 つのオブジェクト グラフが作成され、このオブジェクト グラフがスレッドセーフであることを意味するためです。そして再利用可能。これを機能させることができるかもしれませんが、通常は多くの作業とエラーが発生しやすくなります。そのため、DI コンテナーには、特定のスコープ (Web 要求ごと、WCF 操作ごとなど) でサービスを登録する洗練された方法が含まれていることがよくあります。

DI は、コード編成のための特別な構造を暗示していますか?

いいえ、違います。DI によって特定の組織構造が強制されることはありませんが、最大のメリットを得るには、疎結合とSOLIDを使用してクラスを設計する必要があります。

ドメイン/ビジネス レイヤーは DI フレームワークを参照すべきではないと聞きました。その推奨事項は他のレイヤーにも適用されますか? それとも偽ですか？

はい、このアドバイスは、コンポジション ルートを除いて、システムのすべての部分に当てはまります。ただし、レイヤーはアセンブリと同じではないことに注意してください。この質問とその回答を見てください。

LibraryB 内にファクトリを作成した方がよいでしょうか

これ以上の情報がなければ答えるのは難しいですが (これについては新しい質問を開始することをお勧めします)、一般的には、リクエストごとに 1 つのオブジェクトのみを解決し、コンテナーがグラフ全体を構築できるようにする必要があります。LibraryA が LibraryB の ClassA を使用する場合、LibraryA には ClassA に依存する 1 つまたは複数のクラスが存在します。したがって、コンテナーから ClassA を直接解決する代わりに、LibraryA のクラスの 1 つをコンテナーから (または再帰的に) それらの親の 1 つから解決する必要があります。たとえば、ClassA に依存する (LibA からの) ClassD に依存する XController を持つ MVC アプリケーションがある場合、その場合は XController のみを解決する必要があります。

于 2013-08-14T15:20:01.250 に答える
2

スティーブンの答えに完全に同意し、4番目の質問について：

質問 4: その推奨事項は他のレイヤーにも適用されますか? それとも偽ですか？

ドメイン駆動設計では、ドメイン レイヤーはアプリケーションのコアと見なされ、UI、データベース、インフラストラクチャ レイヤーなどの他のレイヤーはアドオンのようなものです。そのため、ドメイン レイヤーがプライマリになり、他のレイヤーへの参照がありません。これが上記の声明の意味であることを願っています。質問 DDD で与えられたグラフを見てください: どのようにレイヤーを編成する必要がありますか? .

さらに読むために、私はここにDIに関する投稿を持っています。

さらにお問い合わせの場合はお知らせください。ありがとう。

David の最初のコメントへの回答:

データ リポジトリ レイヤーには、http://martinfowler.com/eaaCatalog/repository.htmlおよびhttp://msdn.microsoft.com/en-us/library/ff649690.aspxに従ってリポジトリがあります。

マッピング レイヤーには、Nhibernate やエンティティ フレームワークのようなORM ( http://en.wikipedia.org/wiki/Object-relational_mapping ) が必要です。

データ リポジトリとマッピングは DAL (データ アクセス レイヤー) の一部であり、これらはオプションのパターンですが、データにアクセスするために最も一般的に使用されます。複雑な DAL を使用していない場合は、ここで JDBC または ADO.NE を使用できます。

コードでDIがどのように機能するかをさらに理解するには...私が見つけた最良の場所は、Ninjectユーザーガイドhttp://ninject.codeplex.com/wikipage?title=User%20Guide&referringTitle=Home、特にそこで与えられたウォークスルーです。

于 2013-08-14T15:57:41.670 に答える