IOCコンテナを使用して建設する必要があるものは？

IOCコンテナを介してどのクラスを構築するのか、どのクラスを構成すべきでないのかをどのように決定するのですか。私は両方の極端なプロジェクトに取り組んできました。クラスがログやデータアクセスのような特定の技術を指定している場合にのみインターフェイスを使用すべきです。IOCコンテナを使用して建設する必要があるものは？

ここでは、2つの間に線を引いていますか？

出典

2009-12-09 Kye

DI。すべて。常に。なぜなら。 – Aaronaught

私はどんな線でも描画しません。

APIの分割数を細かくするほど、Single Responsibility Principleに近づくほど、インターフェイスの背後に隠れているものはすべて1つしかない傾向がありますよく

他のタイプに注入された新しいインターフェイスを実装するインプリメンテーションにインターフェイスをインジェクトすることで、ほとんどすべてのレベルでインプリメンテーションの詳細を変えることができる非常に柔軟な構造になり、各コラボレーターは非常に簡単です。

優れたDIコンテナといくつかの賢明な規則では、DIコンテナが自動的に配線の大部分を処理しますので、設定を極端にする必要はありません。

出典

2009-12-09 09:52:03

正直言って、このようなアドバイスは深刻だとは信じられません。マーティン・ファウラー（Martin Fowler）のDIに関する原文の背後にある意図とは完全に矛盾する。また、クラスの実装はすでに "インターフェイスの背後に隠れている"：クラス自体のパブリックインターフェイス！つまり、分離されたインターフェイスは必要ありません。（つまり、一般的な意味で「インターフェース」を意味しましたか？）ほとんどの場合、構成によって、実装の詳細を変更する必要はありません。デフォルトでは過剰設計であり、DIの真の精神と矛盾します。 –

@Rogerio：アドバイスは深刻です。私はこの原則を長年にわたって大成功に収めてきました。私はファウラーを尊敬していますが、私たちはすべての言葉を聖書として使う必要はありません。 Web検索を行い、最先端の.NETコミュニティーがFowlerとBobのおじさんのDIに関する意見をどのように考えているかを調べる。あなたはあなたの心を変えるかもしれません。 –

@マーク：大丈夫です。すべての言葉を「聖句」として使う必要はありませんが、DIと「サービスロケータ」パターンの両方に共通する基本原則は、「設定を使用から分離する」ことです。 IMOは、人々がDI（またはServiceLocator）をその構成の本当の必要性なしに使用しているとき、それを悪用しています。このような悪用はGoFパターンの乱用（実際に多く発生）と同様に、実際のプロジェクトでは顕著なメリットをもたらすことなく開発および保守コストを増加させることで重大な害を及ぼします。それは、私がこのような「根本的な」アドバイス（「より多くの仲間」）を見たときに私に関係するものです。 –

DIコンテナによってインスタンス化されるクラスは、Separated Interfaceを実装し、実行環境に応じて実行時に選択する必要があるものである必要があります。

次に、どのクラスに分離インターフェイスを実装する必要がありますか？

あなたシステムの2つの部分の間の依存関係を壊すために必要（単にすることができますので、それをやって避ける）：新しい別のインタフェースを作成するには、基本的に2つの理由があります。
複数の独立した実装が用意されています（リファクタリングで後で別のインターフェイスを導入するのは通常簡単ですので、「仮説」の考えは避けるべきです）。参考

、参照：http://martinfowler.com/articles/injection.html#SeparatingConfigurationFromUse

出典

2010-01-03 20:31:35

IOCコンテナを使用して建設する必要があるものは？

答えて

関連する問題