问题标签 [service-locator]

这两种模式似乎都是控制反转原则的实现。也就是说，一个对象不应该知道如何构造它的依赖关系。

依赖注入 (DI) 似乎使用构造函数或设置器来“注入”它的依赖项。

使用构造函数注入的示例：

Service Locator 似乎使用了一个“容器”，它连接了它的依赖关系并为 foo 提供了它的 bar。

使用服务定位器的示例：

因为我们的依赖关系只是对象本身，所以这些依赖关系有依赖关系，它们有更多的依赖关系，依此类推。于是，Inversion of Control Container（或DI Container）诞生了。示例：Castle Windsor、Ninject、Structure Map、Spring 等）

但是 IOC/DI 容器看起来与服务定位器完全一样。称它为 DI 容器是一个坏名字吗？IOC/DI 容器只是另一种类型的服务定位器吗？当我们有许多依赖项时，我们主要使用 DI 容器这一事实是否存在细微差别？

现在我们使用 DI/IOC，当我们需要向构造函数传递额外的参数时，我们使用工厂类，例如

现在的问题是我们最终创建了一个完整的lotta工厂类，人们并不总是知道使用它们（他们有时会自己新建它们）。像这样对类进行编码的最大缺点是什么：

Pro：我们现在可以安全地使用构造函数，而不需要工厂类 Con：我们必须引用 Service Locator（我不担心可测试性，它很容易使用模拟容器作为容器的支持服务）。

为什么我们不应该这样做？

编辑：经过一番思考，我认为通过拥有一个私有构造函数，并通过嵌套 Factory 类，我可以将实现和工厂保持在一起，并防止人们不正确地创建类，所以这个问题变得有些没有实际意义。所有关于 SL 脏的观点当然都是正确的，所以下面的解决方案让我很高兴：

这是我之前的问题的后续问题。

我正在尝试为我的 ServiceLocator 类编写测试用例，但它给了我以下错误：

我的测试用例：

getInstance()上面的代码在如下所示的方法上失败：

我知道这ServiceLocator很好用，因为当我从前端测​​试我的应用程序时没有问题。我写这个测试用例的唯一原因是因为我想测试我的DAO。对我来说，测试我的 DAOServiceLocator必须工作（来自JUnit）。

我不知道如何处理错误消息。有没有人想建议一些我可以尝试的东西，希望能奏效？

编辑：ServiceLocator 构造函数

CodeCampServer 源代码包含一个通用的StaticFactory。

我推测这是框架如何与依赖注入良好配合的机制的关键部分。

其子类使用它的 DefaultUnconfiguredState 来提供对它们自己的默认未配置状态的静态访问，依赖解决机制可以用工作的东西代替它。

我找不到任何有关此的文档...

书上有很好的解释吗？（我正在等待亚马逊的送货......）

...或者其他人可以提供一个很好的评论这是什么以及我是否明智地采用这种模式（如果它是一个......）？

更新

由于 Jeffrey Palermo 回答了这个问题，我看到在 MVC2 in Action 的（正在进行的）手稿中，使用用于定位存储库以保持域层无知的工厂讨论和说明了这种模式/风格持久性问题。（见第 23 章）。

默认情况下，使用此工厂会引发异常：

“如何创建存储库的知识不属于工厂。这个工厂仅代表返回存储库的能力”

该示例可以使用几种机制之一来初始化存储库接口的具体实现。在书中的示例中，为了简单起见，他们选择不使用 IOC 容器，并在某些启动逻辑中明确提供它。

“重要的是，核心项目和 UI 项目都不应引用基础设施项目或本质上纯粹是基础设施的库。我们将 NHibernate 完全放在一边，这样应用程序的其余部分就不会关心数据访问正在发生”

关于这一新章节中示例代码的最后一点要注意的是，工厂不再是静态的（至少就面向外部的接口而言不是）。

更新 2

巴勒莫先生在博客上写了更多关于这种特殊风格的抽象工厂（参见 OrderShipperFactory 的实现）。

我也可以考虑“手动依赖注入”（鲍勃叔叔）。

更新 3 - 2016 年 3 月

这里还有另一个例子，尽管 Jeffrey 明确表示这是演示代码，并且注释表明这将在 Mark Seeman 所称的组合根中进行配置（即在应用程序启动时）

我在 Jeffrey 的文章“洋葱架构：第 4 部分 - 四年后”中发现了这一点

在我的项目中，我ISerializers使用程序集扫描仪注册了许多实现。FWIW 这是注册我的代码ISerializers

然后正确注册

等等。

目前，我能够弄清楚如何解决我想要的序列化程序的唯一方法是硬编码服务位置调用

现在我知道在我的课堂上我特别想要 jsonSerializer 所以有没有办法配置一个规则或类似的规则，让 ISerializer 能够根据属性名称连接命名实例？这样我就可以拥有

StructureMap 是否正确解决了这种情况？还是我接近这个错误，也许我应该只注册实现 ISerializer 的具体类型，然后专门使用

对于与具体类类似的东西？

免责声明：我知道 DI 和服务定位器模式之间存在争议。我有一个旨在避免辩论的问题。这个问题是针对服务定位器爱好者的，他们碰巧像 Fowler 一样思考“DI……很难理解……总的来说，除非我需要，否则我宁愿避免它。” 就我的问题而言，我必须避免 DI（故意没有给出原因），所以我不想引发与我的问题无关的辩论。

问题：将 IOC 容器保持在单例中（请记住我上面的免责声明）我可能会看到的唯一问题是使用子容器。大概子容器本身不会是单例的。起初我认为这是一个真正的问题。但是一想起来，我开始认为这正是我想要的行为（子容器不是单例，可以随意 Disposed()）。

然后我的思想进一步进入了哲学领域。因为我是服务定位器的粉丝，所以我想知道子容器的概念首先有多么必要。在我看到有用性的一小部分情况下，要么是满足 DI（无论如何我都在避免），要么问题是可以在不求助于 IOC 容器的情况下解决的。我的想法部分受到了IServiceLocator 接口的启发，该接口甚至都懒得列出“GetChildContainer”方法。

所以我的问题是：如果您是服务定位器的粉丝，您是否发现子容器通常没有实际意义？否则，它们什么时候是必不可少的？

额外的功劳：如果单例中的服务定位器存在其他哲学问题（除了 DI 倡导者提出的问题），它们是什么？

我说过十几种T继承自EntityObjectand的类型IDataObject。我有以下通用接口

我还有数据管理器的基类

我有特定的课程

我想实现服务定位器，它将返回IDataManager<T>for 的实例T

但是我坚持如何在没有大量铸件的情况下以一种简洁的方式实现它。

有任何想法吗？

更新：我曾经使用以下代码来发现类型，以便使用我以前的服务定位器注册它们：

看来我不太了解泛型的反射

考虑这种情况。我有一些业务逻辑，不时需要写入日志。

您将如何获得 ILogger 界面？我看到了两种主要的可能性；

1. 在构造函数上使用依赖注入传递它。
2. 通过单例服务定位器获取它。

您更喜欢哪种方法，为什么？还是有更好的模式？

更新： 请注意，我不需要记录所有方法调用。我只想记录一些在我的方法中可能发生也可能不会发生的（罕见）事件。

在 J2EE 应用程序中，我们在 weblogic 中使用 EJB2。

为了避免浪费时间构建初始上下文和查找 EJB Home 接口，我正在考虑Service Locator Pattern。

但是在网上搜索了一些之后，我发现即使这种模式经常被推荐用于 InitialContext 缓存，也有一些关于 EJB Home 缓存的负面意见。

问题：

• 缓存 EJB Home 查找结果是否安全？
• 如果我的集群节点不再工作会怎样？
• 如果我安装新版本的 EJB 而不刷新服务定位器的缓存会发生什么？

我一次又一次地思考对需要访问某些上下文的 POCO 对象（例如 NH 中的 ISession，IRepository）执行验证的最佳方法。

我仍然可以看到的唯一选择是使用Service Locator，所以我的验证看起来像：

我已经使用了控制反转和依赖注入，由于许多事实，我真的不喜欢 ServiceLocator：

• 更难维护隐式依赖。
• 更难测试代码。
• 潜在的线程问题。
• 仅对 ServiceLocator 的显式依赖。
• 代码变得更难理解。
• 测试时需要注册ServiceLocator接口。

但另一方面，对于普通的 POCO 对象，我看不到任何其他方法可以在没有 ServiceLocator 且仅使用 IoC/DI 的情况下执行上述验证。

目前我在服务层执行这种验证。因此，每当参与者尝试更改用户名（当然可能是不同的用户名）时，服务都会执行此验证。一个明显的缺点是每个使用用户的服务都必须执行此检查（即使是一次调用）。

所以问题是：有没有办法在上述情况下使用 DI/IoC？

谢谢，
德米特里。