制御の反転 (IoC) は、最初に遭遇したときに非常に混乱する可能性があります。
- それは何ですか？
- どの問題を解決しますか?
- いつ使用するのが適切で、いつ使用しないのですか?
608335 次
39 に答える
1831
（Inversion-of-ControlIoC）パターンは、自分自身を直接行動するのではなく、あらゆる種類の（反応を制御する）ものを提供することです（つまり、制御を外部ハンドラー/コントローラーに反転および/またはリダイレクトします）。callback（Dependency-InjectionDI）パターンは、IoCパターンのより具体的なバージョンであり、コードから依存関係を削除することを目的としています。
すべての
DI実装を検討できますがIoC、Dependency-Injectionの実装はコールバックよりも難しいため、これを呼び出すべきではありませIoCん（代わりに、一般的な用語「IoC」を使用して製品の価値を下げないでください）。
DIの例として、アプリケーションにテキストエディタコンポーネントがあり、スペルチェックを提供するとします。標準コードは次のようになります。
public class TextEditor {
private SpellChecker checker;
public TextEditor() {
this.checker = new SpellChecker();
}
}
ここで行ったことにより、TextEditorとの間に依存関係が作成されますSpellChecker。IoCシナリオでは、代わりに次のようなことを行います。
public class TextEditor {
private IocSpellChecker checker;
public TextEditor(IocSpellChecker checker) {
this.checker = checker;
}
}
最初のコード例では、インスタンス化していますSpellChecker（this.checker = new SpellChecker();）。これは、TextEditorクラスがクラスに直接依存していることを意味しSpellCheckerます。
2番目のコード例では、コンストラクターのシグネチャSpellCheckerに依存関係クラスを含めることで抽象化を作成しています（クラスの依存関係を初期化するのではありません）。TextEditorこれにより、依存関係を呼び出して、次のようにTextEditorクラスに渡すことができます。
SpellChecker sc = new SpellChecker(); // dependency
TextEditor textEditor = new TextEditor(sc);
TextEditorこれで、クラスを作成するクライアントは、署名SpellCheckerに依存関係を注入しているため、使用する実装を制御できます。TextEditor
于 2008-08-06T07:22:09.513 に答える
749
制御の反転は、たとえばGUIプログラムのように、プログラムがコールバックしたときに得られるものです。
たとえば、古い学校のメニューでは、次のようになります。
print "enter your name"
read name
print "enter your address"
read address
etc...
store in database
これにより、ユーザーの操作の流れを制御します。
GUIプログラムなどでは、代わりに次のように言います。
when the user types in field a, store it in NAME
when the user types in field b, store it in ADDRESS
when the user clicks the save button, call StoreInDatabase
そのため、制御が逆になります...コンピュータが固定された順序でユーザー入力を受け入れる代わりに、ユーザーはデータが入力される順序と、データがデータベースに保存されるタイミングを制御します。
基本的に、イベントループ、コールバック、または実行トリガーを持つものはすべてこのカテゴリに分類されます。
于 2008-08-06T05:42:36.233 に答える
465
制御の反転とは
次の簡単な 2 つの手順に従うと、制御の反転が完了します。
- 何をするかの部分といつするかの部分を分けます。
- when part がどのpartについてできるだけ知らないかを確認します。およびその逆。
実装に使用しているテクノロジ/言語に基づいて、これらの各手順で使用できる手法がいくつかあります。
--
制御の反転 (IoC)の反転部分は紛らわしいものです。反転は相対的な用語だからです。IoC を理解する最善の方法は、その言葉を忘れることです。
--
例
- イベント処理。イベント ハンドラー (何をするかの部分) -- イベントの発生 (いつ行うかの部分)
- 依存性注入。依存関係を構築するコード (何をするかの部分) -- 必要に応じてクライアントの依存関係をインスタンス化して注入します。これは通常、Dagger などの DI ツールによって処理されます (いつ行うかの部分)。
- インターフェイス。コンポーネント クライアント (いつ行うかの部分) -- コンポーネント インターフェイスの実装 (何をするかの部分)
- xUnit フィクスチャ。Setup と TearDown (何をするかの部分) -- xUnit フレームワークは、最初に Setup を呼び出し、最後に TearDown を呼び出します (いつ行うかの部分)。
- テンプレート メソッド デザイン パターン。テンプレート メソッド いつするかの部分 -- プリミティブ サブクラスの実装 何をするかの部分
- COM の DLL コンテナー メソッド。DllMain、DllCanUnload など (何をするかの部分) -- COM/OS (いつするかの部分)
于 2010-07-22T17:34:19.737 に答える
155
制御の反転（またはIoC）は、自由を手に入れることです（結婚し、自由を失い、制御されています。離婚し、制御の反転を実装したばかりです。これを「分離」と呼びます。優れたコンピューターシステムいくつかの非常に緊密な関係を思いとどまらせます。）柔軟性の向上（オフィスのキッチンはきれいな水道水のみを提供します。これは、飲みたいときに唯一の選択肢です。上司は、新しいコーヒーマシンをセットアップして、制御の反転を実装しました。これで、水道水またはコーヒーのいずれかを選択する柔軟性。）そして依存性が少ない（あなたのパートナーには仕事があります、あなたには仕事がありません、あなたはあなたのパートナーに経済的に依存しているので、あなたはコントロールされています。あなたは仕事を見つけ、あなたは制御の反転を実装しました。良いコンピュータシステムは独立を促進します。）
デスクトップコンピューターを使用すると、奴隷になります（つまり、制御されます）。画面の前に座ってそれを見る必要があります。キーボードを使用して入力し、マウスを使用してナビゲートします。そして、ひどく書かれたソフトウェアはあなたをさらに奴隷にすることができます。デスクトップをラップトップに置き換えると、制御が多少逆になります。あなたはそれを簡単に持って動き回ることができます。これで、コンピューターがコンピューターを制御する代わりに、コンピューターのどこにいるかを制御できるようになりました。
制御の反転を実装することにより、ソフトウェア/オブジェクトのコンシューマーは、制御されたりオプションが少なくなったりする代わりに、ソフトウェア/オブジェクトに対してより多くのコントロール/オプションを取得します。
上記のアイデアを念頭に置いて。私たちはまだIoCの重要な部分を見逃しています。IoCのシナリオでは、ソフトウェア/オブジェクトコンシューマーは洗練されたフレームワークです。つまり、作成したコードは自分で呼び出されないということです。次に、この方法がWebアプリケーションに適している理由を説明しましょう。
コードがワーカーのグループであるとします。彼らは車を作る必要があります。これらの労働者は、車を作るための場所とツール（ソフトウェアフレームワーク）を必要としています。従来のソフトウェアフレームワークは、多くのツールを備えたガレージのようなものになります。したがって、労働者は自分で計画を立て、ツールを使用して車を作る必要があります。車を作るのは簡単なことではありません。労働者が適切に計画し、協力することは本当に難しいでしょう。モダン_ソフトウェアフレームワークは、すべての設備と管理者が配置された現代の自動車工場のようになります。労働者は計画を立てる必要はありません。マネージャー（フレームワークの一部であり、最も賢い人々であり、最も洗練された計画を立てています）は、労働者がいつ仕事をするかを知るための調整を支援します（フレームワークはコードを呼び出します）。ワーカーは、マネージャーが（依存性注入を使用して）提供するツールを使用するのに十分な柔軟性を備えている必要があります。
労働者はマネージャー（フレームワーク）にトップレベルでプロジェクトを管理する制御を与えますが。しかし、何人かの専門家に手伝ってもらうのは良いことです。これがIoCのコンセプトです。
MVCアーキテクチャを備えた最新のWebアプリケーションは、フレームワークに依存してURLルーティングを実行し、フレームワークが呼び出すためのコントローラーを配置します。
依存性注入と制御の反転は関連しています。依存性注入はミクロレベルであり、制御の反転はマクロレベルです。食事を終えるには（IoCを実装）、一口ごとに食べる必要があります（DIを実装）。
于 2013-03-04T19:33:57.607 に答える
99
制御の反転を使用する前に、それには長所と短所があるという事実を十分に認識し、使用する場合はなぜそれを使用するのかを理解する必要があります。
長所：
- コードが分離されるため、インターフェイスの実装を別の実装と簡単に交換できます
- これは、実装ではなくインターフェイスに対してコーディングする強力な動機です
- コードの単体テストを作成するのは非常に簡単です。これは、コンストラクター/セッターで受け入れるオブジェクト以外には依存せず、適切なオブジェクトを分離して簡単に初期化できるためです。
短所：
- IoC は、プログラムの制御フローを逆転させるだけでなく、プログラムをかなり曇らせます。これは、コードを読んである場所から別の場所にジャンプすることができなくなったことを意味します。これは、通常はコード内にある接続がコード内になくなるためです。代わりに、XML 構成ファイルまたは注釈、およびこれらのメタデータを解釈する IoC コンテナーのコード内にあります。
- XML 構成または注釈が間違っているという新しいクラスのバグが発生し、IoC コンテナーが特定の条件下でオブジェクトの 1 つに null 参照を挿入する理由を見つけるのに多くの時間を費やすことができます。
個人的には IoC の長所を見ていて、とても気に入っていますが、可能な限り IoC を避ける傾向があります。これは、ソフトウェアが「実際の」プログラムを構成するクラスのコレクションではなく、他のプログラムによってまとめられる必要があるクラスのコレクションに変わるためです。 XML 構成または注釈のメタデータであり、それがなければバラバラになります (そして崩壊します)。
于 2010-02-12T14:31:57.880 に答える
72
ウィキペディアの記事。私にとって、制御の反転とは、順番に記述されたコードを委任構造に変換することです。プログラムがすべてを明示的に制御する代わりに、プログラムは、特定のことが起こったときに呼び出される特定の関数を備えたクラスまたはライブラリを設定します。
コードの重複を解決します。たとえば、昔は、新しいイベントについてシステムライブラリをポーリングして、独自のイベントループを手動で作成していました。現在、ほとんどの最新のAPIは、関心のあるイベントをシステムライブラリに通知するだけで、イベントが発生したときに通知されます。
制御の反転はコードの重複を減らすための実用的な方法です。メソッド全体をコピーしてコードのごく一部を変更するだけの場合は、制御の反転を使用して対処することを検討できます。制御の反転は、デリゲート、インターフェース、さらには生の関数ポインターの概念を通じて、多くの言語で簡単になります。
このように記述した場合、プログラムのフローを追跡するのが難しくなる可能性があるため、すべての場合に使用することは適切ではありません。これは、再利用されるライブラリを作成するときにメソッドを設計するための便利な方法ですが、コードの重複の問題を実際に解決しない限り、独自のプログラムのコアでは慎重に使用する必要があります。
于 2008-08-06T04:33:19.727 に答える
47
しかし、私はあなたがそれに非常に注意する必要があると思います. このパターンを使いすぎると、非常に複雑な設計とさらに複雑なコードが作成されます。
TextEditor を使用したこの例のように: SpellChecker が 1 つしかない場合は、 IoC を使用する必要がないのではないでしょうか? 単体テストなどを書く必要がない限り...
とにかく：合理的であること。デザインパターンは良い実践ですが、説教すべき聖書ではありません。どこにでも貼り付けないでください。
于 2008-08-06T22:08:27.180 に答える
46
私にとってのIoC / DIは、呼び出し元のオブジェクトに依存関係をプッシュしています。超シンプル。
技術的でない答えは、車のエンジンをオンにする直前にエンジンを交換できることです。すべてが正しく接続されていれば (インターフェイス)、問題ありません。
于 2008-09-19T02:54:35.443 に答える
44
最初の部分だけ答えます。それは何ですか？
Inversion of Control (IoC) は、最初にクラスのインスタンスを作成し、次にクラス インスタンスが依存関係のインスタンスを作成する代わりに、依存関係のインスタンスを最初に作成し、クラスの後者のインスタンスを作成することを意味します (必要に応じて、コンストラクターを介してそれらを注入します)。したがって、制御の反転は、プログラムの制御の流れを反転させます。呼び出し先が(依存関係を作成しながら)制御の流れを制御する代わりに、呼び出し元がプログラムの制御の流れを制御します。
于 2016-01-11T00:49:09.723 に答える
27
制御の反転は、システム内のコンポーネントとレイヤーを分離するために使用されるパターンです。パターンは、コンポーネントの構築時にコンポーネントに依存関係を挿入することで実装されます。これらの依存関係は通常、さらにデカップリングし、テスト容易性をサポートするためのインターフェイスとして提供されます。CastleWindsorやUnityなどのIoC/DIコンテナは、IoCを提供するために使用できるツール（ライブラリ）です。これらのツールは、ライフタイム、AOP /インターセプト、ポリシーなど、単純な依存関係管理を超えた拡張機能を提供します。
a。コンポーネントがその依存関係を管理する責任を負わないようにします。
b。異なる環境で依存関係の実装を交換する機能を提供します。
c。依存関係のモックを通じてコンポーネントをテストできるようにします。
d。アプリケーション全体でリソースを共有するためのメカニズムを提供します。a。テスト駆動開発を行う場合に重要です。IoCがないと、テスト対象のコンポーネントがシステムの他の部分と高度に結合されているため、テストが困難になる可能性があります。
b。モジュラーシステムを開発する場合に重要です。モジュラーシステムは、再コンパイルせずにコンポーネントを交換できるシステムです。
c。特にエンタープライズアプリケーションで対処する必要のある横断的関心事が多数ある場合は重要です。
于 2008-09-19T02:27:33.993 に答える
23
この 2 つの用語についての私の簡単な理解を書き留めておきます。
For quick understanding just read examples*
依存性注入 (DI):
依存性注入とは、一般に、メソッドに依存オブジェクトを作成させるのではなく、メソッドが依存するオブジェクトをパラメーターとしてメソッドに渡すことを意味します。
実際には、メソッドが特定の実装に直接依存しないことを意味します。要件を満たす実装は、パラメーターとして渡すことができます。
このオブジェクトを使用して、依存関係を伝えます。そして春はそれを利用可能にします。
これは、疎結合のアプリケーション開発につながります。
Quick Example:EMPLOYEE OBJECT WHEN CREATED,
IT WILL AUTOMATICALLY CREATE ADDRESS OBJECT
(if address is defines as dependency by Employee object)
コントロール (IoC) コンテナーの反転:
これはフレームワークの一般的な特性であり、IOCは Java オブジェクト
をインスタンス化からその BeanFactory による破棄まで管理します。
-IoC コンテナーによってインスタンス化される Java コンポーネントは Bean と呼ばれ、IoC コンテナーは、Bean のスコープ、ライフサイクル イベント、および構成およびコーディングされた AOP 機能を管理します。
QUICK EXAMPLE:Inversion of Control is about getting freedom, more flexibility, and less dependency. When you are using a desktop computer, you are slaved (or say, controlled). You have to sit before a screen and look at it. Using keyboard to type and using mouse to navigate. And a bad written software can slave you even more. If you replaced your desktop with a laptop, then you somewhat inverted control. You can easily take it and move around. So now you can control where you are with your computer, instead of computer controlling it.
制御の反転を実装することにより、ソフトウェア/オブジェクトの消費者は、制御されたりオプションが少なくなったりするのではなく、ソフトウェア/オブジェクトに対してより多くの制御/オプションを取得します。
設計ガイドラインとしての制御の反転は、次の目的に役立ちます。
特定のタスクの実行が実装から切り離されています。
すべてのモジュールは、その設計目的に集中できます。
モジュールは、他のシステムが何をするかについて何も仮定せず、それらのコントラクトに依存します。
モジュールを置き換えても、他のモジュールに副作用はありません
。ここでは抽象的にします。トピックの詳細を理解するには、次のリンクにアクセスしてください。
例を使った良い読み物
于 2014-11-10T08:43:40.777 に答える
20
あるホテルで会議を行うとしましょう。
多くの人、水差し、プラスチックカップ。
誰かが飲みたいとき、彼/彼女はコップに水を満たして飲み、そのコップを床に投げます。
1時間ほどすると、床がプラスチックのカップと水で覆われます。
コントロールを反転させましょう。
同じ場所での同じ会議ですが、プラスチックのカップの代わりに、ガラスのカップを 1 つ持ったウェイターがいます (Singleton)
そして、彼女はいつもゲストに飲酒を勧めています。
誰かが飲みたいときは、ウェイターからそれを受け取り、飲んで、ウェイターに返します.
衛生的な問題はさておき、飲酒プロセス管理の最後の形式は、はるかに効果的で経済的です。
これは、Spring (Guice などの別の IoC コンテナー) が行うこととまったく同じです。new キーワード (プラスチック カップを取る) を使用して必要なものをアプリケーションに作成させる代わりに、Spring IoC コンテナーは常に、必要なオブジェクト (コップ一杯の水) の同じインスタンス (シングルトン) をアプリケーションに提供します。
あなた自身がそのような会議の主催者であると考えてください。ホテルの管理者にメッセージを送る方法が必要です
例会のメンバーはコップ一杯の水が必要ですが、ケーキは必要ありません。
例：-
public class MeetingMember {
private GlassOfWater glassOfWater;
...
public void setGlassOfWater(GlassOfWater glassOfWater){
this.glassOfWater = glassOfWater;
}
//your glassOfWater object initialized and ready to use...
//spring IoC called setGlassOfWater method itself in order to
//offer to meetingMember glassOfWater instance
}
便利なリンク:-
于 2012-09-26T17:54:41.467 に答える
18
たとえば、タスク #1 はオブジェクトを作成することです。IOC の概念がなければ、タスク 1 はプログラマーによって実行されるはずですが、IOC の概念があれば、タスク 1 はコンテナーによって実行されます。
要するに、コントロールはプログラマーからコンテナーに反転されます。したがって、これは制御の反転と呼ばれます。
ここで 1 つの良い例を見つけました。
于 2010-01-27T12:15:48.473 に答える
18
「IoC」の頭字語とそれが表す名前について最も混乱しているのは、名前があまりにも魅力的であり、ほとんどノイズの名前であることです。
手続き型プログラミングとイベント駆動型プログラミングの違いを説明する名前が本当に必要なのでしょうか? 必要に応じてOKですが、解決するよりも混乱を招く、まったく新しい「人生よりも大きな」名前を選ぶ必要がありますか?
于 2011-01-19T03:50:19.453 に答える
17
制御の逆転とは、食料品店に行ったときに妻が購入する製品のリストを渡したときです。
プログラミング用語では、彼女はgetProductList()あなたが実行している関数にコールバック関数を渡しました - doShopping().
これにより、関数のユーザーが関数の一部を定義できるようになり、より柔軟になります。
于 2017-12-15T18:35:52.217 に答える
14
制御の反転は一般的な原則ですが、依存性注入はこの原則をオブジェクト グラフ構築の設計パターンとして実現します (つまり、オブジェクト自体が別のオブジェクトへの参照を取得する方法を制御するのではなく、オブジェクトが相互に参照する方法を構成が制御します)。
コントロールの反転を設計パターンとして見ると、何を反転しているのかを確認する必要があります。依存性注入は、オブジェクトのグラフ作成の制御を逆転させます。簡単に言えば、制御の反転は、プログラム内の制御の流れの変化を意味します。例えば。従来のスタンドアロン アプリでは、メイン メソッドがあり、そこからコントロールが他のサード パーティ ライブラリに渡されますが (サード パーティ ライブラリの関数を使用した場合)、コントロールの反転によってサード パーティ ライブラリ コードからコードにコントロールが転送されます。 、サードパーティ ライブラリのサービスを利用しているため。ただし、プログラム内で逆にする必要がある他の側面があります。たとえば、コードを実行するためのメソッドとスレッドの呼び出しです。
Inversion of Control についてさらに詳しく知りたい方のために、設計パターンとしての Inversion of Control のより完全な全体像を概説した論文が公開されています (OfficeFloor: using office patterns to better software design http://doi.acm.org/10.1145/ http://www.officefloor.net/about.htmlから無料でダウンロードできます)。
識別されるのは、次の関係です。
制御の反転 (メソッド用) = 依存関係 (状態) 注入 + 継続注入 + スレッド注入
制御の反転に関する上記の関係のまとめ - http://dzone.com/articles/inversion-of-coupling-control
于 2015-10-29T04:27:32.597 に答える
13
非常に簡単な説明がここにあります
http://binstock.blogspot.in/2008/01/excellent-explanation-of-dependency.html
それは言う-
「重要なアプリケーションは、互いに連携してビジネスロジックを実行する、2つ以上のクラスで構成されます。従来、各オブジェクトは、連携するオブジェクト（その依存関係）への独自の参照を取得する責任があります。DIを適用する場合、オブジェクトには、作成時に、システム内の各オブジェクトを調整する外部エンティティによって依存関係が与えられます。つまり、依存関係はオブジェクトに注入されます。」
于 2013-02-22T14:13:23.550 に答える
9
この質問にはすでに多くの回答がありますが、いずれも反転制御用語の内訳を示していないため、より簡潔で有用な回答を提供する機会があると思います。
Inversion of Control は、Dependency Inversion Principle (DIP) を実装するパターンです。DIP は次のように述べています。 1. 高レベル モジュールは低レベル モジュールに依存すべきではありません。両方とも抽象化 (インターフェースなど) に依存する必要があります。2. 抽象化は詳細に依存すべきではありません。詳細 (具体的な実装) は、抽象化に依存する必要があります。
制御の反転には次の 3 つのタイプがあります。
インターフェイス反転 プロバイダーは、インターフェイスを定義すべきではありません。代わりに、コンシューマーがインターフェースを定義し、プロバイダーがそれを実装する必要があります。インターフェイスの反転により、新しいプロバイダーが追加されるたびにコンシューマーを変更する必要がなくなります。
フロー反転 フロー の制御を変更します。たとえば、多くのパラメーターを入力するように要求されたコンソール アプリケーションがあり、パラメーターを入力するたびに Enter キーを押す必要があるとします。ここで Flow Inversion を適用し、ユーザーがパラメーターの入力順序を選択できるデスクトップ アプリケーションを実装できます。ユーザーはパラメーターを編集でき、最後のステップでユーザーは Enter キーを 1 回だけ押す必要があります。
Creation Inversion 以下のパターンで実装できます: Factory パターン、Service Locator、および Dependency Injection。作成の反転は、型間の依存関係を排除するのに役立ち、依存オブジェクトの作成プロセスを、これらの依存オブジェクトを使用する型の外に移動します。依存関係が悪いのはなぜですか? コード内で新しいオブジェクトを直接作成すると、テストが難しくなります。再コンパイルせずにアセンブリ内の参照を変更することはできません (OCP 原則違反)。デスクトップ UI を Web UI に簡単に置き換えることはできません。
于 2019-08-12T15:36:49.930 に答える
5
クラス内にオブジェクトを作成することを密結合と呼び、Spring は設計パターン (DI/IOC) に従ってこの依存関係を取り除きます。クラスで作成するのではなく、コンストラクターで渡されるクラスのオブジェクト。さらに、より一般的な構造を定義するために、コンストラクターでスーパークラス参照変数を提供します。
于 2015-05-13T08:52:39.357 に答える
4
概念を理解するために、制御の反転 (IoC) または依存性反転の原則 (DIP) には、抽象化と反転という 2 つのアクティビティが含まれます。依存関係の挿入 (DI) は、数少ない反転手法の 1 つにすぎません。
これについてもっと読むには、私のブログを ここで読むことができます
- それは何ですか？
実際の動作が境界の外から来るようにするのは実践です (オブジェクト指向プログラミングのクラス)。境界エンティティは、その抽象化 (たとえば、インターフェイス、抽象クラス、オブジェクト指向プログラミングのデリゲート) のみを認識します。
- どのような問題を解決しますか?
プログラミングに関しては、IoC はモノリシック コードをモジュール化し、さまざまな部分を分離し、単体テスト可能にすることで、モノリシック コードを解決しようとします。
- 適切な場合とそうでない場合はいつですか？
モノリシック コード (非常に単純なプログラムなど) だけが必要な状況でない限り、ほとんどの場合は適切です。
于 2016-06-03T01:46:24.477 に答える
3
Castle Windsor のようなコンテナーを使用すると、メンテナンスの問題がさらに解決されます。データベースにアクセスするコンポーネントを、コード行を変更せずにファイル ベースの永続性を使用するコンポーネントに交換できるのは素晴らしいことです (構成の変更で完了です)。
そして、ジェネリックに取り掛かると、さらに良くなります。レコードを受信してメッセージをパブリッシュするメッセージ パブリッシャーがあるとします。何をパブリッシュするかは問題ではありませんが、レコードからメッセージに何かを取得するにはマッパーが必要です。
public class MessagePublisher<RECORD,MESSAGE>
{
public MessagePublisher(IMapper<RECORD,MESSAGE> mapper,IRemoteEndpoint endPointToSendTo)
{
//setup
}
}
一度書いたことがありますが、今では、さまざまな種類のメッセージを発行すると、このコード セットに多くの種類を挿入できます。また、同じタイプのレコードを受け取り、それらを異なるメッセージにマップするマッパーを作成することもできます。Generics で DI を使用することで、非常に小さなコードを記述して多くのタスクを実行できるようになりました。
確かに、テスト容易性に関する懸念はありますが、IoC/DI の利点に次ぐものです。
私は間違いなくIoC/DIが大好きです。
3. やや複雑な中規模のプロジェクトがあると、より適切になります。痛みを感じ始めた瞬間に適切になると思います。
于 2008-09-19T04:59:27.483 に答える