依赖注入与服务定位器.doc

依赖注入与服务定位器（Dependency Injection/Service Location）? 接下来的例子有些长，但解释了为什么我们使用依赖注入与服务定位器. 首先，假设我们正在开发一个组件，叫SomeComponent，它执行的内容现在还不重要。 我们的组件需要依赖数据库的连接。 在下面第一个例子中，数据库的连接是在组件内部建立的。这种方法是不实用的；事实上这样做的话，我们不能改变创建数据库连接的参数或者选择不同的数据库系统，因为连接是当组件被创建时建立的。 为了解决这样的情况，我们建立一个setter，在使用前注入独立外部依赖。现在，看起来似乎是一个不错的解决办法： 想一下，假设我们使用这个组件在应用内的好几个地方都用到，然而我们在注入连接实例时还需要建立好几次数据的连接实例。 如果我们可以获取到数据库的连接实例而不用每次都要创建新的连接实例，使用某种全局注册表可以解决这样的问题： 现在，让我们设想一下，我们必须实现2个方法，第一个方法是总是创建一个新的连接，第二方法是总是使用一个共享连接： 到目前为止，我们已经看到依赖注入怎么解决我们的问题了。把依赖作为参数来传递，而不是建立在内部建立它们，这使我们的应用更加容易维护和更加解耦。不管怎么样，长期来说，这种形式的依赖注入有一些缺点。 例如，如果这个组件有很多依赖， 我们需要创建多个参数的setter方法??来传递依赖关系，或者建立一个多个参数的构造函数来传递它们，另外在使用组件前还要每次都创建依赖，这让我们的代码像这样不易维护： 假设我们必须在应用的不同地方使用和创建这些对象。如果当你永远不需要任何依赖实例时，你需要去删掉构造函数的参数，或者去删掉注入的setter。为了解决这样的问题，我们再次回到全局注册表创建组件。不管怎么样，在创建对象之前，它增加了一个新的抽象层： 瞬间，我们又回到刚刚开始的问题了，我们再次创建依赖实例在组件内部！我们可以继续前进，找出一个每次能奏效的方法去解决这个问题。但似乎一次又一次，我们又回到了不实用的例子中。 一个实用和优雅的解决方法，是为依赖实例提供一个容器。这个容器担任全局的注册表，就像我们刚才看到的那样。使用依赖实例的容器作为一个桥梁来获取依赖实例，使我们能够降低我们的组件的复杂性： 这个组件现在可以很简单的获取到它所需要的服务，服务采用延迟加载的方式，只有在需要使用的时候才初始化，这也节省了服务器资源。这个组件现在是高度解耦。例如，我们可以替换掉创建连接的方式，它们的行为或它们的任何其他方面，也不会影响该组件。 Phalcon\DI 是一个实现依赖注入和定位服务的组件，而且它本身就是一个装载它们的容器。 因为Phalcon是高度解构的，整合框架的不同组件，使用Phalcon\DI是必不可少的。开发者也可以使用这个组件去注入依赖和管理的应用程序中来自不同类的全局实例。 基本上，这个组件实现了 [控制反转](/wiki/%E6%8E%A7%E5%88%B6%E5%8F%8D%E8%BD%AC) 的模式。使用这种模式，组件的对象不用再使用setter或者构造函数去接受依赖实例，而是使用请求服务的依赖注入。这减少了总的复杂性，因为在组件内，只有一个方法去获取所需的依赖实例。 另外，该模式增加了代码的可测试性，从而使其不易出错。 框架本身或者开发者都可以注册服务。当一个组件A需要组件B(或者它的类的实例) 去操作，它可以通过容器去请求组件B，而不是创建一个新的组件B实例。 这个工作方法给我们提供了许多优势： 我们可以很容易的使用一个我们自己建立的或者是第三方的组件去替换原有的组件。 我们完全控制对象的初始化，这让我们在传递它们的实例到组件之前，根据需要设置这些对象。 我们可以在一个结构化的和统一组件内获取全局实例。 服务可以使用不同方式去定义： 使用数组的方式去注册服务也是可以的： 在上面的例子中，当框架需要访问request服务的内容，它会在容器里面查找名为‘request’的服务。 在容器中将返回所需要的服务的实例。当有需要时，开发者可能最终需要替换这个组件。 每个方法（在上面的例子证明）用于设置/注册服务方面具都具有优势和劣势。这是由开发者和特别的要求决定具体使用哪个。 通过字符串设置一个服务是很简单，但是缺乏灵活性。通过数组设置服务提供了更加灵活的方式，但是使代码更复杂。匿名函数是上述两者之间的一个很好的平衡，但是会导致比预期的更多维护。 Phalcon\DI 对每个储存的服务提供了延迟加载。除非开发者选择直接实例化一个对象并将其存储在容器中，任何储存在里面的对象(通过数组，字符串等等设置的)都将延迟加载，即只要当使用到时才实例化。 就像你之前看到的那样，这里有几种方法去注册服务。下面是简单调用的例子： 使用字符串注册服务需要一个