问题标签 [service-locator]

我一直将Common Service Locator视为抽象 IoC 容器的一种方式，但我注意到有些人强烈反对这种类型。

人们是否建议永远不要使用它？一直在用吗？或者有时使用它？如果有时，那么在什么情况下你会使用它，你会在什么情况下不使用它。

我是 Flex 和 Cairngorm 的新手。在使用 ServiceLocator 时，我确实遇到了问题：错误：C0001E：只能实例化一个 ServiceLocator 实例。

我的代码是这样的：

在 Serives.mxml 中：

在 Delegate.as 中，我有片段：

在 Main.xml 中，片段如下：

当我加载需要 httpservice 的某个模块的第二个实例时，就会弹出这个美妙的小错误消息。

有没有办法在不切换到另一个框架的情况下解决这个问题？

最良好的祝愿，

Shuo（来自中国）

为了解耦代码，您可以使用服务定位器，但这与全局变量/状态不同吗？

我知道这些经常运行接口，所以你传入一个接口并返回一个具体的类，但我的问题仍然存在。

例如：

在这里，该类需要在其他地方创建的 MyType，但不是通过链（通过构造函数等）向下传递 MyType，而是以这种方式获取它。

_{在我作为开发人员的职业生涯早期，我问过这个问题——在此之前我没有遇到过这种模式。Anthony 在服务定位器上确定了我的观点（因此现在是选定的答案）——事实上，我认为它们与其他人一样是反模式。提供的链接是一个很好的起点 - 但在这么长时间之后，为了在某种程度上回答我自己的问题，它们充当全局状态，应该避免。更喜欢标准的依赖注入；）}

创建可设计的 .NET 组件时，您需要提供默认构造函数。从IComponent文档：

要成为一个组件，一个类必须实现 IComponent 接口并提供一个基本构造函数，该构造函数不需要参数或 IContainer 类型的单个参数。

这使得无法通过构造函数参数进行依赖注入。（可以提供额外的构造函数，但设计者会忽略它们。）我们正在考虑的一些替代方案：

• 服务定位器

  不要使用依赖注入，而是使用服务定位器模式来获取依赖项。这似乎是什么 IComponent.Site。GetService用于。我想我们可以创建一个可重用的 ISite 实现（ConfigurableServiceLocator？），它可以配置必要的依赖项。但是这在设计师的环境中是如何工作的呢？

• 通过属性进行依赖注入

  通过属性注入依赖项。如果需要在设计器中显示组件，请提供默认实例。记录需要注入哪些属性。

• 使用 Initialize 方法注入依赖项

  这很像通过属性注入，但它将需要注入的依赖项列表保存在一个地方。这样，所需依赖项的列表就会被隐式记录，当列表发生变化时，编译器会帮助你解决错误。

知道这里的最佳做法是什么吗？你怎么做呢？

---

编辑：我已经删除了“（例如 WinForms UserControl）”，因为我打算将问题与一般组件有关。组件都是关于控制反转的（参见UMLv2 规范的第 8.3.1 节），所以我不认为“你不应该注入任何服务”是一个好的答案。

---

编辑 2：花了一些时间使用 WPF 和 MVVM 模式才最终“得到”马克的答案。我现在看到视觉控制确实是一个特例。至于在设计器表面上使用非可视组件，我认为 .NET 组件模型从根本上与依赖注入不兼容。它似乎是围绕服务定位器模式设计的。也许这将随着在System.ComponentModel.Composition命名空间中添加到 .NET 4.0 中的基础设施而开始改变。

使用 Service Locator 类为要绑定的 WPF 页面提供 ViewModel 时。ViewModel 应该是单例范围还是工厂范围？WPF 应用程序通常是一个更好的主意吗？

我知道在 Silverlight 中，Singleton 更适合作为用户控件且仅在前台移入和移出的页面。但是在尝试应用这种模式之前，我一直在更新页面实例和它们各自的虚拟机，每次它们要被加载。

我和我的同事已经经历了每个选项的所有优点和缺点，没有什么是对我们的场景更好的选择。

谢谢。

我一直在阅读依赖注入框架。我真的爱上了分离关注点并让对象完成其核心工作的想法——这无疑是一个优秀且长期存在的设计原则！

然而，我在 DI 框架上阅读的越多，我就越担心：1）它们“自动”解决依赖关系的方式 2）关于配置文件中引入的极端复杂性

就第 2 点而言，我看到我的客户花费数百万美元来培训人们使用产品，其中重要的部分是如何“不”接触配置文件。管理员现在害怕这些配置文件。

尽管如此，我看到了另一种称为服务定位器的模式，我可以在应用程序开始时很好地组装所有我想要的“全局”服务（可能是应用程序主机或应用程序上下文或其他）。让这个服务定位器在全球范围内可用，瞧！

但是，我发现当我需要基于某些标准（谁知道？）的不止一种“全局”服务时，使用服务定位器方法的灵活性会降低！

所以，在这里我比以前更困惑于该采取哪个方向。虽然我非常喜欢设计原则，但现有框架的复杂性让我望而却步！

我的担忧是真的吗？其他人有同样的感觉吗？如果是这样，对于如此庞大的压倒性“框架”有什么好的选择吗？

与单例相比，使用服务定位器的优点和缺点是什么？我读过单身人士很糟糕，但我想知道服务定位器是否通常是一种更好的做事方式。

我一直在研究在我的 Web 应用程序中实现 IoC 的细节，但以一种利用 Microsoft.Practices.ServiceLocation 的方式。我专门使用 Autofac 和 asp.net 集成，但我想让自己对其他容器开放。按照这个问题，我担心如何在我的网络应用程序代码中访问容器。

我有一个“核心”库，主要定义要解析的接口。我的网络应用程序和其他应用程序也使用这个核心库。定义通用接口非常方便。我认为这是一个访问 IoC 容器的好地方，我使用静态类做到了这一点。诀窍是将容器注入静态类。

在 Web 环境中这很棘手，因为每个请求的容器可能不同，而在非 Web 应用程序中，它可能一直都是相同的。起初我尝试使用一种方法直接注入容器，但在下一个 Web 请求中很快就失败了！所以我想出了这个：

现在在我的 global.asax.cs 我这样做：

解决依赖的呼吁看起来像

因此，我没有传递一个特定的容器，而是传递一个知道如何获取容器的委托。对于非 Web 应用程序，委托可能只会返回 builder.Build() 提供的内容。

我对专家的问题是，这有意义吗？我有一种简单的方法可以解决依赖关系，而无需知道容器产品是什么或容器本身来自何处。你怎么看？

有没有人见过/尝试编写使用 Guice 风格配置系统的服务定位器模式？

目前我有一个使用命令模式的 GWT 项目（恰好使用 GWT-RPC），其中我的 RPC servlet 看起来像这样......

在我当前执行方法的实现中，我这样做......

我想做的是找出一种方法来摆脱巨大的 if 语句。我需要某种方式来注册 ActionImpl1 的类应该委托给 TransactionNService 的另一个实现。

有任何想法吗？我正在考虑向 HashMap 添加条目，其中键是 Action 的类，值是 ServiceImpl 的类。我有一个对 ServiceImpl 类的引用，我可以使用 Guice 来获取 TransactionService 的实例。

我有一个需要使用多个 WCF 服务的 silverlight 应用程序。服务的端点（url）不能在 silverlight 应用程序或配置文件中硬编码。必须从本身是 WCF 服务的服务注册表中查询它们。问题是我必须先使用异步调用来查询服务端点，然后才能创建真实服务代理的实例。我想不出等待响应或阻止对实际服务的调用的好方法。在 silverlight 应用程序中使用 Service Registry / Service Locator 模式的最佳方式是什么？