问题标签 [common-service-locator]

在我当前的项目中，我使用 SolrNet 和 OAuth.Net。两个库都使用 Common Service Locator。SolrNet 将自定义 IoC 容器实现设置为定位器提供程序。OAuth.Net 的定位器提供程序在我的代码中设置（目前我使用的是示例中使用的 Windsor）。问题从这里开始，因为

实际上是替换 ServiceLocator.Current 静态属性值。

有什么建议吗？在这种情况下，最佳实践是什么？

在此先感谢， Hristo

目前，当我需要将依赖项注入基类时，我使用以下代码：

我必须在所有子类中编写大量重复的代码。为了避免这些重复的代码，我想我可以使用 CommonServiceLocator 将依赖项注入到基类中：

这似乎要简单得多，但我不确定这是否是一个好习惯。

谢谢

如何从 Autofac 修改以下内容以使用 Common Service Locator（其中 _context 的类型为 IComponentContext）：

上面的代码取自 Orchard，我正在尝试删除对 Autofac 的依赖。通常我会尝试类似的东西：

但是，这返回 null 并且我看不到如何处理 TypedParameter 的东西，因为我不明白它在做什么。

如果有人可以提供帮助，我将不胜感激。谢谢

I'm building a library for conversational natural language processing. In many ways it acts much like MVC3 in that it has Controllers and Action Methods. It also uses dependency injection in much the same way as MVC3 does when instantiating constructors for the Controller classes. The main differences being that an English sentence replaces both the URL and the form values of HTTP; routing is based on matching sentence structure; and the parameters passed in are the meanings of words and phrases used in the English sentence.

Currently it uses Autofac for Dependency Injection but I'd like to remove that dependency and allow callers to use any DI container.

If I use the P&P / Codeplex Common Service Locator project in my solution then callers would still need to provide their own implementations of IServiceLocator against the instance of that interface exposed by my engine. If I use IDependencyResolver from MVC3 instead there are at least existing implementations of the mapping from the various DI container to that interface.

Should I:-

1. use the Common Service Locator and force callers to implement the mapping classes.
2. use the MVC 3 IDependencyResolver interface which already has mappings to other containers.
3. accept a object as the dependency resolver and duck type it to get the one method I need from it so I can use the MVC3 interface without even taking a dependency on ASP.NET MVC3.
4. other?

我正在尝试使用 Ninject 作为 Caliburn Micro for WP7.1 Mango 的 IOC 容器。我发现这样做的唯一帖子创建了 NinjectServiceLocator 并将其设置为 ServiceLocator 上的提供程序。问题：1）“CommonServiceLocator.NinjectAdapter”程序集中定义的 NinjectServiceLocator 依赖于“Microsoft.Practices.ServiceLocation”的 v 1.0.0.0。Microsoft.Practices.ServiceLocation 是否已移植到 WP 7.1？

2）我尝试使用 nuget 安装“ninject.wp7”，但没有安装并出现以下错误： 无法安装包“Ninject.WP7 2.2.0.0”。您正在尝试将此包安装到以 'Silverlight,Version=v4.0,Profile=WindowsPhone71' 为目标的项目中，但该包不包含与该框架兼容的任何程序集引用

是否有解决方法可以在 Mango 上进行这项工作。我真的在寻找使用带有 CM 的 IOC，它允许我扫描程序集以注册视图模型，而不是手动连接默认 SimpleContainer 中的每种类型。

我最近从 StructureMap 跳到了 Ninject。一切都很顺利，直到我意识到 Ninject 没有 StructureMap 的 ObjectFactory（服务定位器）的版本。

我发现了 Common Service Locator，它为包括 Ninject 在内的任何 IOC 容器提供了服务定位器模式。它在我的“启动”项目中效果很好——例如网站。但是，如果我尝试从子项目（例如 Core 或 Data）访问 ServiceLocator.Current，那么 CommonServiceLocator 似乎不知道我的任何依赖关系映射。

如何从子项目中使用 Common Service Locator？

注意我知道关于 ServiceLocator 作为模式/反模式的辩论。我发现在作为反模式的 ServiceLocator 和作为反模式的贫血域模型之间存在权衡 -有时使用服务定位器更容易且可维护。

我想猜测“环境容器”与它是一个静态类这一事实有关，但这只是一个猜测。

或者这是指标准模式？（即我真的需要阅读 GoF 书的封面）

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

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

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

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

谢谢

据我所知，依赖注入与服务位置不同。但是Unity 应用程序块包含Common Service Locator库（我认为它是一个服务定位器）。应该如何使用该库以及何时使用它，以及它是否被统一本身用于依赖注入？
注意：请不要引用CommonServiceLocator CodePlex 主页上的用法。

我开始学习后一直在思考一个问题......如果我们必须满足所有所需的导入，Prism为什么我们需要使用a 。Service locatorMEF

MEF 的通用服务定位器链接

如果两者共存，我无法理解它的用途。

它是否允许Attributeless Imports（我相信必须使用 Exports 完成导出）？？

我还在通用服务定位器上阅读了此链接，但如果机器人共存，我并没有完全了解它们的用法。

对此 regads 的任何帮助都会有所帮助... :)