Tag: 服务定位器

没有服务定位器的工厂模式

我目前只是在努力编写一个不依赖服务位置的工厂类。 我能想到的唯一其他选择是使用构造函数注入来注入所有可能的实例，但这可能会导致意外，因为类是通过引用传递的。 一旦可能的提供商数量增加，它也可能会变得昂贵和混乱。 提供者本身是完全复杂的类，它们有自己的依赖关系，因此手动构造是不可能的。 更新了服务位置示例： public class ProviderFactory : IProviderFactory { private readonly IProviderConfigurationService _providerConfigurationService; public enum SearchType { Foo, Bar } public ProviderFactory(IProviderConfigurationService providerConfigurationService) { _providerConfigurationService = providerConfigurationService; } public Collection GetProviderInstances(SearchType searchType) { // Provider configuration service will read a XML/DB store to retrieve list of search providers applicable for a search type […]

如果不能使用dependency injection怎么办？

在经过多次踢和尖叫之后，我开始接受DI，尽管随着依赖关系的增长，SL看起来更加清晰。 然而，对于DI来说，IMO仍然有一个显着的阻碍： 当您无法控制对象的实例化时，DI是不可能的。 在ASP.NET世界中，示例包括：HttpModule，HttpHandler，Page等。 在上面的场景中，我们将使用静态服务位置来解析依赖关系，通常是通过HttpContext.Current ，它总是从当前线程推断出范围。 所以，如果我们要在这里使用静态SL，那么为什么不在其他地方使用它呢？ 答案很简单：咬牙并在必要时使用SL（如上所述），但尝试并支持DI？ 如果是这样的话：一次性使用静态SL可能会破坏整个应用程序的一致性吗？ 基本上在其他地方撤消DI的辛勤工作？

如何在XML配置中声明Unity InjectionFactory

我正在将Unity配置移动到web.config文件。 我坚持如何将以下代码配置迁移到xml格式： var container = new UnityContainer(); container.RegisterType(new InjectionFactory(x=> HttpContext.Current.User)); return container; 以下是XML声明：

如何避免服务定位器反模式？

我正在尝试从抽象基类中删除服务定位器，但我不确定要用什么来替换它。 这是我所得到的一个假例子： public abstract class MyController : Controller { protected IKernel kernel; public MyController(IKernel kernel) { this.kernel = kernel); } protected void DoActions(Type[] types) { MySpecialResolver resolver = new MySpecialResolver(kernel); foreach(var type in types) { IMyServiceInterface instance = resolver.Get(type); instance.DoAction(); } } } 这个问题是派生类的instanciator不知道内核必须具有什么绑定才能使MySpecialResolver不引发exception。 这可能是内在难以处理的，因为我从这里不知道我将要解决哪些类型。 派生类负责创建types参数，但它们不是任何地方都是硬编码的。 （这些类型基于派生类的组合层次结构中存在的属性。） 我试图通过延迟加载代理来解决这个问题，但到目前为止我还没有想出一个干净的解决方案。 更新 这里确实存在两个问题，一个是IoC容器被传递给控制器​​，充当服务定位器。 这很容易删除 – 您可以使用各种技术在调用堆栈中向上或向下移动位置。 第二个问题是困难的问题，如果要求在运行时才暴露，如何确保控制器具有必要的服务。 它应该从一开始就很明显：你不能！ […]

IDependencyResolver是反模式吗？

我正在为遗留的ASP.NET应用程序设计一些体系结构更改。 我为一些模拟ASP.NET MVC的IDependencyResolver的依赖解析的类原型。 我不会发布，因为它几乎是相同的界面，但用其他自然语言。 我发现它可能被认为是服务位置，反过来通常（在某些情况下不完全）被谴责依赖于dependency injection。 不过，我找不到任何反对使用ASP.NET MVC的依赖项解析实现的建议。 ASP.NET MVC的IDependencyResolver是否被视为反模式？ 这是件坏事吗？