タグ付けされた質問 「service-locator」

どちらのパターンも、制御の反転の原則の実装のように見えます。つまり、オブジェクトは依存関係の構築方法を知らないはずです。 Dependency Injection（DI）は、コンストラクターまたはセッターを使用して依存関係を「注入」するようです。 コンストラクターインジェクションの使用例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo(IBar bar) { this.bar = bar; } //... } Service Locatorは「コンテナ」を使用しているようです。これは依存関係を結び付け、fooにバーを提供します。 サービスロケーターの使用例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo() { this.bar = Container.Get<IBar>(); } //... } 私たちの依存関係は単なるオブジェクトそのものなので、これらの依存関係には依存関係があり、さらに多くの依存関係があり、以下同様です。このようにして、Inversion of …

304 design-patterns  dependency-injection  service-locator 

最近、Service Locatorのアンチパターンに関するMark Seemannの記事を読みました。 著者は、ServiceLocatorがアンチパターンである2つの主な理由を指摘しています。 APIの使用に関する問題（これで問題 ありません）クラスがサービスロケーターを使用する場合、ほとんどの場合、クラスにはPARAMETERLESSコンストラクターが1つしかないため、依存関係を確認することは非常に困難です。ServiceLocatorとは対照的に、DIアプローチは、コンストラクターのパラメーターを介して依存関係を明示的に公開するため、IntelliSenseで依存関係を簡単に確認できます。 メンテナンスの問題（これは私を困惑させます） 次の例を考えます サービスロケーターアプローチを採用するクラス'MyType'があります。 public class MyType { public void MyMethod() { var dep1 = Locator.Resolve<IDep1>(); dep1.DoSomething(); } } 次に、クラス 'MyType'に別の依存関係を追加します public class MyType { public void MyMethod() { var dep1 = Locator.Resolve<IDep1>(); dep1.DoSomething(); // new dependency var dep2 = Locator.Resolve<IDep2>(); dep2.DoSomething(); } } そして、ここが私の誤解の始まりです。著者は言う： …

137 design-patterns  dependency-injection  anti-patterns  service-locator