Unity应用架构设计(8)——使用ServiceLocator实现对象的注入

对象的 『注入』 是企业级软件开发经常听到的术语。如果你是一个 Java 程序员，一定对注入有着深刻的映像。不管是SSH框架还是SSM框架，Spring 全家桶永远是绕不过去的弯。通过依赖注入，可以有效的解耦应用程序。在uMVVM框架中，我提供了另外一种对象注入的方式，称为Service Locator 『服务定位模式』 。与Spring的依赖注入不同的是，Service Locator 内部以字典的形式维护了对象的依赖关系，外部通过Key的形式获取 『Resolve』 到对应的Value，从而达到解耦。

为什么要注入对象

简而言之，为了解耦，达到 不去依赖 具体的对象。

实际上解耦是个非常 『虚』 的概念，只有软件到达一定的复杂度之后才会明白解耦和的好处，对于一个简单如『Hello World』程序而言，你很难理解为什么需要解耦。

假设有个 Foo 类，需要通过调用 SomeService 对象的方法去执行一些任务。很简单的需求，你可能会这样写：

public class Foo
{
ISomeService _service;

public Foo()
{
_service = new SomeService();
}

public void DoSomething()
{
_service.PerformTask();
...
}
}

这当然没问题，但有隐患，Foo 紧耦合了 SomeService，当需求变了，你不得不打开 Foo 类，然后找到构造函数，重新调用另外的 Service，改完之后编译，然后部署、测试等等。如果是Web程序，你还得在等到晚上去部署。

既然紧耦合了，那就解耦，你可能会这样写：

public class Foo
{
ISomeService _service;

public Foo(ISomeService service)
{
_service = service;
}

public void DoSomething()
{
_service.PerformTask();
...
}
}

这样很不错，Foo 与具体的 Service 解耦了，那怎样去实例化 Foo 呢？比如有一个 Bar 类：

public class Bar
{
public void DoSomething()
{
var foo = new Foo(new SomeService());
foo.DoSomething();
...
}
}

遗憾的是，Bar 和 SomeService 又耦合了。然后你又改成这样：

public class Bar
{
ISomeService _service;

public Bar(ISomeService service)
{
_service = service;
}

public void DoSomething()
{
var foo = new Foo(_service);
foo.DoSomething();
...
}
}

通过构造函数传递参数，Bar 和 SomeService 解耦了。但你打算怎样去实例化 Bar 呢？

额...(-｡-😉

Spring中的依赖注入

Spring中将上述 Foo、Bar 类对SomeService的依赖关系，通过构造函数或者setter方法来实现对象的注入。

可以看到Spring将依赖关系配置到XML中，在运行时，从IoC容器工厂获取 『Bean(即：实例)』 并将依赖关系注入。

难道我们需要在Unity3D 中定义XML来配置吗？这会不会太麻烦了？

使用ServiceLocator实现对象的注入

其实对象的 『注入』 有很多实现方式，依赖注入 『DI』 只是其中一种，大名鼎鼎的Spring框架就是非常优秀的依赖注入框架，而uMVVM中实现的注入式通过ServiceLocator实现。

什么是ServiceLocator？

简单说ServiceLocator内部以字典的形式维护了对象的依赖关系，外部通过Key的形式获取到对应的Value，从而达到解耦，如下图所示：

要实现对象的 『注入』 ，还缺一个非常重要的对象，就是IoC容器工厂，所有需要被注入的对象都是由容器工厂创建。那我们哪里去找工厂呢？还记得上篇文章的内容了吗？我们已经预先定义了3种不同创建对象的工厂，他们分别为 Singleton Factory，Transient Factory以及 Pool Factory，这些就是我们需要的IoC工厂。

既然 ServiceLocator内部以字典的形式维护了依赖关系，那么首先需要创建一个字典：

private static readonly Dictionary<Type, Func