Questions tagged «service-locator»

两种模式似乎都是控制反转原理的一种实现。也就是说，对象不应该知道如何构造其依赖项。 依赖注入（DI）似乎使用构造函数或setter来“注入”它的依赖项。 使用构造函数注入的示例： //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>(); } //... } 因为我们的依赖关系只是对象本身，所以这些依赖关系具有依赖关系，后者甚至具有更多的依赖关系，依此类推。因此，控制容器（或DI容器）的反转诞生了。示例：温莎城堡，Ninject，结构图，弹簧等） 但是，IOC / …

303 design-patterns  dependency-injection  service-locator 

最近，我阅读了Mark Seemann的有关Service Locator反模式的文章。 作者指出了ServiceLocator是反模式的两个主要原因： API使用问题（我非常满意） 当类使用Service定位器时，很难看到其依赖关系，因为在大多数情况下，类只有一个PARAMETERLESS构造函数。与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