问题标签 [service-locator]

我在几个关于在 asp.net mvc3 中使用 Unity 的教程中看到了这行代码。我的印象是服务定位器是一种反模式，而不是最佳实践。这个服务定位器是不是定义的反模式，还是这行代码/这个实现被认为是不好的做法。

我有一个带有 DDD 数据层的框架，它使用服务定位器模式。但是，目前我使用存储所有引用的全局静态ServiceLocator类。我想将其重构为正确的实现，其中类实现IServiceProvider接口并删除全局静态ServiceLocator类。

IServiceProvider现在，除了实体类之外，几乎在所有地方都可以使用接口扩展现有类。问题是我认为实体类必须实现非常奇怪IServiceProvider，但我确实需要一种访问服务提供者的方法，以便能够通过我的 IoC 容器解析存储库。

无需IServiceProvider在我的实体上实施服务定位器模式的最佳方法是什么？

几个月后，我将不得不对我的应用程序进行水平分区。我的应用程序中有某些服务需要大量的 CPU 和内存，为了可扩展性，我希望将其分片到多个 JVM。

我有一个 EAR，它封装了我需要分区的服务。当我这样做时，服务的客户端（例如 UI）将需要能够处理服务的特定实例。例如，假设我有一个名为 Account 的服务，但实际上我有 3 个该服务的实例在三个不同的 JVM 中运行（但都在同一个 Java EE 域中）。假设我有一个可以从帐户 ID 映射到特定 VM 的服务定位器，我将如何访问可以为该特定帐户提供服务的 EJB？

我可以看到的一个潜在解决方案是利用应用程序容器为单独应用程序中的 EJB 提供的 JNDI 名称。如果我以不同的名称将模块部署三个不同的时间，我可以进行 JNDI 查找以找到它们：

java:global/AccountServer1/AccountFacade

java:global/AccountServer2/AccountFacade

java:global/AccountServer3/AccountFacade

为了使它工作，我永远不能使用依赖注入来访问 AccountFacade，我必须使用能够获取 AccountID 并将其映射到 Account 应用程序之一的 AccountLocator EJB。如果我想变得棘手，我可能会实现一个“本地”帐户外观，它透明地进行查找，假设方法的参数可以识别要使用的服务器......

这种方法可行吗？有更好的选择吗？

在阅读了 Mark Seemann的“.NET 中的依赖注入”之后，我远离了反模式的服务定位器。

在阅读MVC 4 上的发行说明后，我看到：

通过 DependencyResolver 改进控制反转 (IoC)：Web API 现在使用 MVC 的依赖解析器实现的服务定位器模式来获取许多不同设施的实例。

因此，我对微软为什么会在 2012 年使用服务定位器感到好奇和困惑。

我正在 global.asax 的 Application_Start 方法中通过以下方式设置与 Solr 的连接：Startup.Init<ApartmentDoc>("http://localhost:8080/solr");

我有一个 DAO 库项目，我试图用它来调用 Solr 服务器。问题是当我尝试从库类访问我的 solr 连接的实例时，我在 ServiceLocator.Current 上得到一个空引用异常。

我是 DI 和 SolrNet 的新手，因此将不胜感激。

谢谢，德鲁

我正在尝试按类型从 ServiceLocator (MEF) 获取值。

示例：给出所有类型为 DMControl 的控件

列表为空。当我从 ServiceLocator 打开列表时，有类似的控件。如果我得到一个带有导出密钥的 DMControl 实例，也可以。为什么我不能获得一种类型的所有控件？！

一般来说，使用方法但没有字段或属性的类的实例化是否有很多开销？

我正在开发一个 ASP.NET MVC 应用程序，该应用程序大量使用构造函数注入，到目前为止，一些控制器有多达 10 个依赖项。但是由于大量的依赖项，我IMyAppServiceProvider通过 MVC 3 中的 DependencyResolver 求助于一个接口和类，它提供对所有依赖项的通用访问。

我删除了所有特定于应用程序的代码，并使用我的基本设置创建了一个Gist（但这不包括下面提到的 BaseController 设置）。

我还创建了一个接受IMyAppServiceProvider. 所有控制器都继承自这个基类。基类接受IMyAppServiceProvider对象并为所有各种服务提供受保护的变量。代码看起来像这样：

这使得控制器的代码“干净利落”。没有私有/受保护变量，构造函数中没有赋值，并且服务由基类受保护变量引用。 但是，每个请求都会实例化我的应用程序使用的每一个服务，无论特定控制器是否使用所有这些服务。

我的服务很简单，只包含带有一些业务逻辑和数据库交互的方法调用。它们是无状态的，没有类字段或属性。因此，实例化应该很快，但我想知道这是否是最佳实践（我知道这是一个加载术语）。

在编写代码时，我们应该能够识别两大类对象：

• 注射剂
• 新品

http://www.loosecouplings.com/2011/01/how-to-write-testable-code-overview.html

http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/

• 可注入对象是在其构造函数中公开依赖关系的对象（服务），这些依赖关系通常使用 IoC 容器解决，这些对象只能在其构造函数中请求其他可注入对象

• Newable 是在其构造函数中也暴露依赖关系的对象，但 newables 只能请求其他可更新对象（实体、值对象），可更新对象的另一个特征是它们不应该持有对可注入对象的引用

但是在写代码的时候，我们经常需要将一个服务（injectable）“注入”到一个Entity（newable）中

我一直在想，也许在可更新对象中公开服务依赖项更好地在方法级别进行，但这听起来需要做很多工作......每次调用方法时都要考虑解决依赖关系...... . 这闻起来就像我们必须使用服务定位器反模式

我解决这个问题的方法是：

• 使用暴露依赖项的方法创建接口（该方法中将使用服务）

• 为接口创建一个扩展方法并将其放置在不同的命名空间中，可能在另一个程序集中，然后将调用包装到使用服务定位器解决依赖关系的原始方法

这样做，我们可以在新对象和可注入对象之间保持一致的分离，并且能够轻松地在我们的新对象中使用服务

• 你怎么看？
• 在扩展方法中使用服务定位器被认为是一种不好的做法？
• 您将如何对扩展方法调用进行单元测试？

这个问题可能更适合程序员堆栈。如果是这样，我会移动它。不过我想我可能会在这里得到更多的答案。

到目前为止，我的域中的所有接口依赖项都是使用来自执行程序集的 DI 解决的，目前该程序集是一个 .NET MVC3 项目（+ Unity IoC 容器）。但是，我遇到了一种情况，我认为服务定位器可能是更好的选择。

域中有一个实体存储（缓存）来自 URL 的内容。具体来说，它存储来自元数据 URL 的 SAML2 EntityDescriptor XML。我有一个带有单一方法的接口 IConsumeHttp：

当前实现使用 System.Net 中的静态 WebRequest 类：

缓存 XML 内容的实体作为非根存在于更大的实体聚合中。对于聚合的其余部分，我正在实现一个有点大的 Facade 模式，它是 MVC 控制器的公共端点。我可以像这样在外观构造函数中注入 IConsumeHttp 依赖项：

我看到的问题是外观中只有一个方法依赖于这个接口，所以为整个外观注入它似乎很愚蠢。类的对象创建WebRequestHttpConsumer不应该增加很多开销，但是域没有意识到这一点。

相反，我正在考虑将实体的所有缓存逻辑移到单独的静态工厂类中。不过，代码将取决于IConsumeHttp. 所以我正在考虑在静态工厂方法中使用静态服务定位器来解析 IConsumeHttp，但前提是需要初始化或刷新缓存的 XML。

我的问题：这是一个坏主意吗？在我看来，确保适当缓存 XML 元数据应该是域的责任。作为其他相关操作的一部分（例如获取 SAML Authn 请求和响应的元数据、更新 SAML EntityID 或元数据 URL 等），域会定期执行此操作。还是我只是担心太多？

我们尝试将 LightCore 作为默认服务定位器集成到我们的 Metadata-/ORM-Framework 中。因此，我们喜欢框架内的一些默认注册，框架用户（=应用程序开发人员）可以用他自己的实现以某种方式“否决”（如果他喜欢这样做的话）。这应该如何使用 LightCore IoC 容器或其他 IoC 容器来完成？

我们尝试了什么：

我们为 Foo 注册了两个类作为合约。使用上面的代码，我们总是得到第一个（Foo 的实例）返回。所以这里没有推翻。顺便说一句：我们喜欢获取 Foo2 的实例。

我们将其从使用具体类更改为使用接口：

有了这个，我们在 Resolve<>() 中得到一个解析异常，告诉我们找不到注册。如果我们删除第二个“Register()”语句，它会以我们获取 Foo 实例的方式工作。

我们不确定我们是否遗漏了一些一般概念。这与其他 IoC 的工作方式是否相同？否决/覆盖注册的推荐方法是什么？

关于这个主题的任何帮助都会很棒 - 不仅适用于 LightCore。

更新： 我使用 SimpleInjector IoC 容器为上述场景设置了一些测试。使用此容器，需要在构造函数中指定 AllowOverridingRegistration = true ，它将按预期工作。所以看起来 LightCore 根本不正确支持这个用例，但其他人支持。

更新： 我们得到了 LightCore 创建者的快速回复，说 LigtCore 根本不支持覆盖注册。所以似乎没有办法解决这些场景注册覆盖 LightCore，所以我们从 LightCore 切换到 SimpleInjector。

以下 SimpleInjector 配置符合我们当前的四个要求：

干杯，马克