你的位置:首页 > ASP.net教程

[ASP.net教程][翻译] 服务定位器是反模式


原文:Service Locator is an Anti-Pattern

服务定位器模式广为人知,Martin Fowler在文章中专门描述过它。所以它一定是好的,对不对?

并不是这样。服务定位器实际上是个反模式,应该避免使用。我们来研究一下。简单来讲,服务定位器隐藏了类之间的依赖关系,导致错误从编译时推迟到了运行时,并且,在引入破坏性更改时,这个模式导致代码不清晰,增加了维护难度。

OrderProcessor 示例

我们用依赖注入话题中常见的OrderProcessor示例作说明。OrderProcessor 处理订单的过程是:先验证,通过后再发货。下面的代码使用静态的服务定位器:

public class OrderProcessor : IOrderProcessor{  public void Process(Order order)  {    var validator = Locator.Resolve<IOrderValidator>();    if (validator.Validate(order))    {      var shipper = Locator.Resolve<IOrderShipper>();      shipper.Ship(order);    }  }}

这里,我们用服务定位器替换了new 操作符,服务定位器的实现代码如下:

public static class Locator{  private readonly static Dictionary<Type, Func<object>> services = new Dictionary<Type, Func<object>>();   public static void Register<T>(Func<T> resolver)  {    Locator.services[typeof(T)] = () => resolver();  }   public static T Resolve<T>()  {    return (T)Locator.services[typeof(T)]();  }  public static void Reset()  {    Locator.services.Clear();  }}

Register方法用来配置服务定位器。真实项目中的服务定位器要复杂的多,不过这些代码在这里足够用了。这个实现灵活且可扩展,也可以替换服务进行测试。那么,问题在哪?

API 使用问题

先假设我们是 OrderProcessor 类的消费者,它不是我们自己写的,而是由第三方提供的。我们还没有用Reflector来看它的代码。编码时 Visual Studio 智能感知会给出以下提示:

 

我们看到一个默认构造函数,就是说,我们可以创建一个新实例然后立刻调用Process 方法:

var order = new Order();var sut = new OrderProcessor();sut.Process(order);

这段代码在执行时会抛出 KeyNotFoundException,因为 IOrderValidator 还没有注册到服务定位器。在没看到 OrderProcessor 源码之前很难知道哪里出了问题。只有在仔细检查源码(或者用Reflector)或者查阅文档之后才能搞清楚,原来在使用 OrderProcessor 之前要首先向服务定位器(它是个完全不相干的静态类)注册一个 IOrderValidator 实例。

进行单元测试时,我们可能像下面这么写:

var validatorStub = new Mock<IOrderValidator>();validatorStub.Setup(v => v.Validate(order)).Returns(false);Locator.Register(() => validatorStub.Object);

但是,由于定位器内部的存储变量是静态的,每个测试执行完,都需要调用 Reset 方法来清理一下,这是单元测试时的问题。

所以,很难说这样的 API 设计提供了好的开发体验。

维护问题

除了消费者会遇到问题以外,OrderProcessor 的维护人员也会遇到问题。

假设我们要做一点扩展,处理订单时增加 IOrderCollector.Collect 方法的调用。实现起来是不是很容易?

public void Process(Order order){  var validator = Locator.Resolve<IOrderValidator>();  if (validator.Validate(order))  {    var collector = Locator.Resolve<IOrderCollector>();    collector.Collect(order);    var shipper = Locator.Resolve<IOrderShipper>();    shipper.Ship(order);  }}

 

机械的看确实容易 ---- 调用一下 Locator.Resolve 方法和 IOrderCollector.Collect 方法就行了,只增加了一点点代码。

那么,这个更改是不是破坏性的呢?

这个问题其实不好回答。编译可以通过,但是上面那个单元测试会失败,因为没有注册 IOrderCollector。如果是生产环境的程序会发生什么?IOrderCollector 可能已经注册过了,比如其他组件使用过它,这种情况下就不会报错。但是也可能没有注册过。

这里的本质问题是很难说清这个更改是不是破坏性的。你必须理解整个程序是怎么使用服务定位器的,编译器在这里帮不上忙。

变种:非静态类的服务定位器

那么有没有办法修复这些问题?一个变种是使用非静态的服务定位器,像这样:

public void Process(Order order){  var locator = new Locator();  var validator = locator.Resolve<IOrderValidator>();  if (validator.Validate(order))  {    var shipper = locator.Resolve<IOrderShipper>();    shipper.Ship(order);  }}

不过,为了配置它,还是需要一个静态的变量来存储注册的内容,像这样:

public class Locator{  private readonly static Dictionary<Type, Func<object>> services = new Dictionary<Type, Func<object>>();   public static void Register<T>(Func<T> resolver)  {    Locator.services[typeof(T)] = () => resolver();  }   public T Resolve<T>()  {    return (T)Locator.services[typeof(T)]();  }   public static void Reset()  {    Locator.services.Clear();  }}

换言之,不管定位器是不是静态的,都没有结构上的差异,问题还在。

变种:抽象的服务定位器

另一个变种似乎更符合依赖注入的做法:把服务定位器作为接口的实现。

public interface IServiceLocator{  T Resolve<T>();}
public class Locator : IServiceLocator{ private readonly Dictionary<Type, Func<object>> services; public Locator() { this.services = new Dictionary<Type, Func<object>>(); } public void Register<T>(Func<T> resolver) { this.services[typeof(T)] = () => resolver(); } public T Resolve<T>() { return (T)this.services[typeof(T)](); }}

使用时,要把服务定位器注入到消费者类中。构造函数注入是注入依赖项的较好方式,我们来调整一下 OrderProcessor 的代码:

public class OrderProcessor : IOrderProcessor{  private readonly IServiceLocator locator;   public OrderProcessor(IServiceLocator locator)  {    if (locator == null)    {      throw new ArgumentNullException("locator");    }    this.locator = locator;  }   public void Process(Order order)  {    var validator = this.locator.Resolve<IOrderValidator>();    if (validator.Validate(order))    {      var shipper = this.locator.Resolve<IOrderShipper>();      shipper.Ship(order);    }  }}

现在事情好些了没有?

使用时,我们看到的是这样的提示:

作用其实很有限,仅仅是 OrderProcessor 需要一个 ServiceLocator ---- 比无参构造函数的版本好了一点,但是仍然不知道 OrderProcessor 具体需要哪些服务。下面的代码可以编译,但在运行时还是会抛出 KeyNotFoundException:

var order = new Order();var locator = new Locator();var sut = new OrderProcessor(locator);sut.Process(order);

所以,从维护人员的观点看,改善并不多。增加新的依赖项时,还是不知道是不是引入了破坏性的更改。

总结

使用服务定位器产生的问题,不是由于特定的实现造成的(尽管这也可能是个问题),而是因为它是反模式。它对于开发者和维护者来说都有问题。使用构造函数注入依赖项时,编译器可以给使用者和开发者很多帮助,如果使用服务定位器,这些好处就没有了。