キャッスルウィンザーとは何ですか？
私は長年のWindows開発者であり、win32と初期のCOMに歯を磨きました。私は2001年から.Netに取り組んでいるので、C＃とCLRにかなり精通しています。 Stack Overflowに参加し始めるまで、Castle Windsorについて聞いたことはありませんでした。 Castle Windsorの「Getting Started」ガイドを読みましたが、クリックではありません。
この老犬に新しいトリックを教え、Castle Windsorをエンタープライズアプリに統合する理由を教えてください。
Castle Windsorは、制御ツールの反転です。そのような他のものがあります。
ビルド済みおよび配線済みの依存関係を持つオブジェクトをすぐに使用できます。 「new」演算子ではなく、リフレクションと構成によって作成されたオブジェクトグラフ全体。
ここから開始： http://tech.groups.yahoo.com/group/altdotnet/message/10434
メール送信クラスがあるとします。 EmailSender。別のクラスのWorkflowStepperがあるとします。 WorkflowStepper内では、EmailSenderを使用する必要があります。
常にnew EmailSender().Send(emailMessage);と言うことができます
しかし、その-newを使用すると、変更が難しいタイトカップリングが作成されます。 （これは、結局のところ、非常に不自然な例です）
では、WorkflowStepper内でこの不良少年を更新する代わりに、コンストラクタに渡しただけではどうでしょうか。
そのため、呼び出し元はだれでもEmailSenderを更新する必要がありました。
new WorkflowStepper(emailSender).Step()
1つの責任（google SRP）のみを持つこれらの小さなクラスが何百もあり、WorkflowStepperでそれらのいくつかを使用するとします。
new WorkflowStepper(emailSender, alertRegistry, databaseConnection).Step()
EmailSenderまたはWorkflowStepperを書いているときにAlertRegistryの詳細を心配しないことを想像してください。
あなたはあなたが働いている懸念について心配するだけです。
オブジェクトと依存関係のこのグラフ（ツリー）全体が実行時に接続されると想像してください。
WorkflowStepper stepper = Container.Get<WorkflowStepper>();
必要な場所にすべての依存関係が自動的に入力された本物のWorkflowStepperを取得します。
newはありません
ただhappens-何が何を必要としているかを知っているからです。
また、より適切に設計されたDRYコードをテスト可能かつ再現可能な方法で記述することで、より少ない欠陥を書くことができます。
IoCは、開発チーム（PM、BA、BOを含む）の生産性と楽しさを高めるための正しい方向への足がかりだと思います。開発者とテストの間で懸念の分離を確立するのに役立ちます。それは、フレームワークが出入りする可能性があるので柔軟性を考慮して設計するときに安心を与えます。
IoC（CWまたはNinjectなど）が突き刺すという目標を達成するための最善の方法は、政治＃1および＃2を排除することです。これらの2つのソリューションは、IoCに関連していないようですか？彼らです ：）
Mark Seemannは、IOCのサブセットであるDI（Dependency Injection）に関する優れた本を執筆しました。また、多くのコンテナを比較しています。私はこの本を十分お勧めできません。本の名前は：「.Netでの依存性注入」 https://www.manning.com/books/dependency-injection-in-dot-net
城ウィンザーはDependency Injection container.これは、これを利用して依存関係を注入し、新しいキーワードを使用して依存関係を作成せずに使用できることを意味します。例えばリポジトリまたはサービスを作成し、多くの場所で使用したい場合は、まずサービス/リポジトリを登録する必要があり、必要な場所に注入して使用を開始できます。キャッスルウィンザーを学ぶために私が従った以下のチュートリアルをご覧ください。
リンク 。
それがあなたを助けることを願っています。
簡単に言えば。あなたのコードにいくつかのクラスが埋まっていると想像してください。つまり、そのクラスのインスタンスを作成するすべてのものがそれらの依存関係を取得する必要があるため、通常はインスタンスの作成場所まで少しの設定を渡すために、クラスのロードをリファクタリングする必要があります。
そのため、多くのクラスが不必要に変更され、設定値を1つの大きな設定クラスにまとめてしまいますが、これもまた悪い...または最悪の場合はService Locatorになります！
IoCを使用すると、クラスはその面倒なしにすべての依存関係を取得でき、インスタンスの有効期間もより明確に管理できます。