一、Dependency Injection(依赖注入)
依赖注入(DI)是一个软件设计模式,处理代码如何得到它所依赖的资源。
关于DI更深层次的讨论,可以参观Dependency Injection(http://en.wikipedia.org/wiki/Dependency_injection),Inversion of Control(http://martinfowler.com/articles/injection.html),也可以参观软件设计模式的书。
1. DI in a nutshell(简说DI)
object或者function,只能够通过以下三种方式获取他们依赖的资源:
1) 可以通过new运算符创建依赖的资源。
2) 可以通过全局变量查找依赖的资源。
3) 可以通过参数传入依赖的资源。
1、2两种方式,并不是最佳的,因为它们对依赖关系进行hard code,这使得修改依赖关系时,不是不可能,但会变得比较复杂。这对于测试来说尤其是个问题,通常在独立测试时,希望能够提供模拟的依赖资源。
第3种方法相对来说最可行,因为它去除了从组件(component)中定位依赖的责任。依赖仅仅交给组件就可以了。
this.greeter.greet(name);
}
上面的例子,SomeClass不用关心定位greeter这个依赖,它仅仅在运行时传递greeter。
这样是比较合适的,但它将获取依赖资源的责任交给了负责构建SomeClass的代码那里。
为了管理创建依赖的责任,每一个angular应用都有一个injector(http://code.angularjs.org/1.0.2/docs/api/angular.injector)。injector是一个服务定位器,负责定位并创建依赖的资源。
请求依赖,解决了hard code的问题,但它意味着injector需要贯穿整个应用。传递injector,会破坏Law of Demeter(http://baike.baidu.com/view/823220.htm)。为了纠正这个问题,我们将依赖查找的责任转给injector。
上面说了那么多,看看下面经我修改过的例子,合并了原文的两个例子,分别在angular内、外使用inject: