问题标签 [service-locator]

我正在编写一个库，它将为其消费者提供公共类型的集合。

我想让这个库依赖注入中的类型友好。这意味着每个类都需要有一个构造函数，通过它可以指定被初始化对象的每个依赖项。我还希望库遵守配置原则的约定。这意味着如果消费者想要默认行为，他可以使用无参数构造函数，并且对象将以某种方式为自己构造依赖关系。

在示例（C#）中：

我的第一个解决方案是使用服务定位器模式。

代码如下所示：

不过，我对此有疑问。服务定位器已被标记为反模式（链接），我完全同意这些论点。另一方面，Martin Fowler 提倡在这种情况下使用服务定位器模式（图书馆项目）（链接）。我想小心并消除在显示服务定位器确实是个坏主意后重写库的可能必要性。

所以总而言之 - 你认为服务定位器在这种情况下很好吗？我应该以完全不同的方式解决我的问题吗？欢迎任何想法......

我已经编程了一段时间，但从未有兴趣从理论上了解每个概念的含义，我可能正在使用各种编程概念，但并不知道。

Service Locator：对我来说，是指通过减少代码量来加速开发的快捷方式的记录。一个问题是：Locator 是否可以仅引用命名空间/类，或者我可以拥有一个变量注册表？

以下是我对它的理解：

依赖注入（和依赖注入容器）：在对象中注入对象，无论工厂模式如何，都可以更快地访问这些对象。DI 容器呢？

以下是我对它的理解：

控制反转：不了解这种设计模式（或了解但不知道我所做的是否是 IoC）

那么，理论上（最好有简单的例子），这些概念中的每一个是什么意思？我是正确的，还是有什么问题/可以改进？

谢谢！

这是通过使用构造函数注入来避免 ServiceLocator 模式的正确方法吗？

使用我想避免的 ServiceLocator 消费类。

使用 MEF 的解决方案。修改上面的 *EntitySomething's 以导出，并且

实际上还没有尝试过，但想知道是否还有其他方法可以实现这一目标。

谢谢

我有一个基于 MVVM 的 WPF 应用程序，带有 Caliburn.Micro 和 Ninject。我有一个名为 ShellViewModel 的根视图模型。它有几个在 Caliburn 的 Bootstrapper 中配置的依赖项（通过构造函数注入）。到目前为止，一切都很好。

在某个地方，有一个带有几个按钮的 MenuViewModel，它们依次打开具有自己依赖项的其他视图模型。这些视图模型不是在创建根对象期间创建的，但我仍然想从我的 IoC 容器中将依赖项注入它们。

我已经阅读了关于服务定位器与依赖注入的这个问题，并且我理解所提出的要点。

然而，我的印象是，我的 MenuViewModel 需要能够访问我的 IoC 容器才能正确注入动态制作的视图模型......这是我试图避免的事情。还有其他方法吗？

最近我读了很多关于应用程序设计模式的东西：关于 D​​I、SL 反模式、AOP 等等。原因——我想在设计上做出妥协：松散耦合、干净且易于使用。DI 似乎几乎是一种解决方案，除了一个问题：横切和可选依赖导致构造函数或属性污染。因此，我为此提出了自己的解决方案，我想知道您对此有何看法。

Mark Seemann（DI 书籍的作者和著名的“SL 是反模式”声明的作者）在他的书中提到了一种称为 Ambient Context 的模式。尽管他说他不太喜欢它，但这种模式仍然很有趣：它就像旧的好单例，只是它是作用域的并提供默认值，因此我们不必检查 null。它有一个缺陷——它没有而且它不知道它的范围以及如何处置自己。

那么，为什么不在这里应用服务定位器呢？它可以解决环境上下文对象的作用域和处置问题。在你说它是反模式之前：这是你隐藏合同的时候。但在我们的例子中，我们隐藏了 OPTIONAL 合同，所以 IMO 并没有那么糟糕。

这里有一些代码来说明我的意思：

编辑：我意识到不问具体问题与堆栈溢出设计相冲突。因此，我会将一篇最好地描述为什么这种设计不好或更好地提供更好的解决方案（或者可能是添加？）的帖子标记为答案。但是不要建议 AOP，它很好，但是当你真的想在你的代码中做一些事情时，它不是一个解决方案。

编辑 2：我添加了对 ServiceLocator.Current 的检查是否为空。这就是我的代码要做的事情：在未配置 SL 时使用默认设置。

我不知道如何使用 UnityContainer 进行跟踪。

我需要注册两个具体类，以便ServiceLocator.ResolveAll<X>返回两个实例。在同一时间Resolve<A>，Resolve<B>也应该工作。此外，我在注册服务时不能自己实例化它们。

如果我使用命名注册X来进行ResolveAll工作，则会创建每个具体类的两个实例。如果我对所有接口使用命名注册，那么Resolve<A>并且Resolve<B>不起作用。如果我使用这种方法，那么ResolveAll什么都不返回。

如何使用 UnityContainer 解决问题？

我正在尝试使用 Caliburn Micro 和 nHibernate 为新的 LOB MVVM 项目设计架构，现在正在研究 DI 和 IOC。

许多引导 Caliburn Micro 的示例使用 MEF 作为 DI\IOC 机制。

我正在苦苦挣扎的是，MEF 似乎相当受欢迎，但 Mef [Imports] 注释的想法在我看来就像是另一种服务定位器？

我是否遗漏了有关 MEF 的某些内容，几乎所有我见过的示例都没有正确使用它，或者我完全不了解它的使用方式，从而绕过了整个服务定位器问题？

前段时间我有一个类似的问题，但对整个 IoC/DI 主题以及我想要实现的目标的掌握要少得多，所以又来了....

我正在建立一个图书馆供我们​​公司内部使用。公共 API 中最常用的部分已经对 IoC 友好，但在较低级别的区域中，仍有相当多的新功能在进行，我想摆脱它们（尽管此时更多是出于正式原因而不是实际原因必要性）。

这本身很容易做到，但是当然每次使用库时，都必须重新连接所有组件。由于这看起来几乎总是一样的，我通常只是将这些默认注册包装在 Autofac 模块中并完成它。

（这里的问题 1：这个模块是放在主库程序集中还是应该是一个独立的包，即使 Autofac 可能是库中唯一使用的 IoC 容器？）

现在的问题是，我是公司目前唯一真正了解 IoC 目的或知道 IoC 容器做什么的开发人员，更不用说它是如何使用的了，告诉其他人他们是一个坏主意可以使用 Autofac 包，也可以使用穷人的 DI 手动构建十几个对象的图形。（我认识这些人——他们只会不理会它，自己建造他们需要的东西，因为无论如何我对我所有的小班都很疯狂。）

我想解决这个问题的是添加类似服务定位器的东西，从中提取常用类型的预配置对象（看起来与 Autofac 模块连接的那些相同），可能由轻量级 IoC 容器在内部连接.

我知道服务定位器是一种反模式以及它会产生哪些类型的问题，我永远不会将其用作（我的）对象组合方式，而是作为 IoC/SOLID 受损的“捷径”，是否可行? 我还有什么其他选择？在这种情况下，将 Autofac 模块包含在库中并让“服务定位器”充当它的前端是否有意义？

假设我有一个BaseForm依赖于ILogger或IResourceManager或类似的东西。目前，它使用服务定位器解决了所需服务的正确实现，我知道这是一种反模式。

• 使用构造函数注入是解决这种依赖关系的正确方法吗？
• 我是否必须BaseForm在容器中注册我的（及其派生类型）才能创建具有已解析依赖项的实例？这不是把一切都复杂化了吗？
• 使用包裹在服务定位器周围的静态工厂是不是很糟糕？
• 抛开单元测试不谈，我真的会因为使用服务定位器反模式而受到惩罚吗？

很抱歉一次问了很多问题。我已经阅读了以下 SO 问题和许多其他问题，但阅读它们只会增加我的困惑：

• 如何使用依赖注入而不是服务定位器
• 依赖注入和服务定位器模式有什么区别？
• 如何避免服务定位器反模式？

我们有一个大型解决方案（> 100 个项目），几乎每种类型都使用服务定位器（示例 1）或我们自己的类型字典（示例 2）进行实例化。

例如我们有：

或者

第二个示例转到配置文件以查找要使用反射实例化的具体对象。

跟踪代码时会变得更加困难——因为不清楚使用的是什么具体类型——所以我们必须多次检查映射，因为我们试图学习代码的一部分。以上面的例子为例，按下 F12 on:quote.DoSomething()将带您进入界面定义。

实现起来也有点困难——我们需要一个接口 + 具体类 + 配置映射，而替代方案只有 1 个类。

想一想——我不知道有任何东西被“换掉”为另一种类型——所以虽然我们已经实现了 IoC，但我们没有使用它，或者至少——很少使用它。

所以 - 它真的值得吗？我们是否错误地/太多地实施了它？我是不是误会了什么？