martin-hughes/auryn

Auryn是一个用于启动面向对象PHP应用程序的依赖注入器。

维护者

详细信息

github.com/martin-hughes/auryn

主页

源代码

问题

安装: 93

依赖者: 1

建议者: 0

安全: 0

星标: 6

关注者: 2

分支: 65

开放问题: 2

v1.4.7 2024-09-16 19:40 UTC

Requires

  • php: >=7.4.0 <=8.4

Requires (Dev)

Replaces

MIT 1ab84baa760fc9a7dc448b7aa1d1660751721cd4

dependency injectiondicioc

This package is auto-updated.

Last update: 2024-09-16 20:04:50 UTC

README

auryn是一个递归依赖注入器。使用auryn启动并连接S.O.L.I.D.面向对象PHP应用程序。

维护状态

此包现在处于仅维护阶段。 我仍将修复错误并更新以支持新PHP版本。在新项目中，我建议使用PSR-11的实现。

此包的原始版本 - rdlowrey/auryn - 已基本被放弃。该包的当前维护状态甚至没有进入master分支 - 它只到达了dev分支！

尽管如此，我仍然喜欢这个包，尽管它现在的利用率相对较低。我的意图是保持它通过测试，并在新的PHP版本发布时运行。这需要跟随任何功能弃用进行一些更新。

我还打算尽可能在尽可能旧的PHP版本上测试它。限制因素很可能是PHPUnit - 最终当前使用的版本（9.6）将不支持最新的PHP版本，我必须升级。到那时，这个包将不再在PHP的旧版本上测试，可能会出现问题。我将在composer.json中注明这一点。

重大API更改和新功能不太可能被纳入包中。

它的工作原理

auryn根据类构造函数签名中指定的参数类型提示递归实例化类依赖项。这需要使用反射。你可能听说过“反射很慢”。让我们澄清一下：如果你做得不对，“任何事情”都可能“慢”。反射比磁盘访问快一个数量级，比从远程数据库检索信息快几个数量级。此外，每个反射都提供了缓存结果的机会，如果你担心速度的话。auryn缓存它生成的任何反射，以最大限度地减少潜在的性能影响。

auryn 不是服务定位器。不要通过将注入器传递到你的应用程序类中来将其变成一个服务定位器。服务定位器是一种反模式；它隐藏类依赖关系，使代码更难维护，并使你的API说谎！你应该只在引导阶段使用注入器将应用程序的不同部分连接起来。

指南

基本用法

高级用法

示例用例

需求和安装

  • auryn需要PHP 7.4或更高版本。它在PHP 7.4、8.0、8.1和8.2（RC）至少一个版本上进行了测试

安装

Github

你可以从github仓库克隆最新的auryn迭代

$ git clone git://github.com/martin-hughes/auryn.git

Composer

你还可以使用composer在你的项目composer.json中包含auryn作为依赖项。相关的包是rdlowrey/auryn。

或者使用composer cli要求该包

composer require martin-hughes/auryn

手动下载

归档的标记版本也可在项目的标签页手动下载，请访问 标签页

基本用法

要开始使用注入器，只需创建一个 Auryn\Injector ("注入器") 类的新实例

<?php
$injector = new Auryn\Injector;

基本实例化

如果某个类在其构造函数签名中没有指定任何依赖项，那么使用注入器生成它的意义不大。然而，为了完整性，考虑以下操作可以获得等效的结果

<?php
$injector = new Auryn\Injector;
$obj1 = new SomeNamespace\MyClass;
$obj2 = $injector->make('SomeNamespace\MyClass');

var_dump($obj2 instanceof SomeNamespace\MyClass); // true

具体类型提示的依赖项

如果某个类仅请求具体依赖项，则可以使用注入器注入它们，而不需要指定任何注入定义。例如，在以下场景中，您可以使用注入器自动为 MyClass 提供所需的 SomeDependency 和 AnotherDependency 类实例

<?php
class SomeDependency {}

class AnotherDependency {}

class MyClass {
    public $dep1;
    public $dep2;
    public function __construct(SomeDependency $dep1, AnotherDependency $dep2) {
        $this->dep1 = $dep1;
        $this->dep2 = $dep2;
    }
}

$injector = new Auryn\Injector;
$myObj = $injector->make('MyClass');

var_dump($myObj->dep1 instanceof SomeDependency); // true
var_dump($myObj->dep2 instanceof AnotherDependency); // true

递归依赖实例化

注入器的一个关键特性是它递归遍历类依赖树来实例化对象。这仅仅是一种说法，即，“如果您实例化对象 A，该对象需要对象 B，则注入器将实例化对象 B 的任何依赖项，以便 B 可以实例化并提供给 A”。这最好用一个简单的例子来说明。考虑以下类，其中 Car 需要一个 Engine，而 Engine 类本身也有具体的依赖项

<?php
class Car {
    private $engine;
    public function __construct(Engine $engine) {
        $this->engine = $engine;
    }
}

class Engine {
    private $sparkPlug;
    private $piston;
    public function __construct(SparkPlug $sparkPlug, Piston $piston) {
        $this->sparkPlug = $sparkPlug;
        $this->piston = $piston;
    }
}

$injector = new Auryn\Injector;
$car = $injector->make('Car');
var_dump($car instanceof Car); // true

注入定义

您可能已经注意到，之前的例子都是演示了使用显式、类型提示的具体构造函数参数来实例化类。显然，您的许多类都不会符合这个模式。一些类将类型提示接口和抽象类。一些类将指定标量参数，这在 PHP 中没有类型提示的可能性。还有其他参数将是数组等。在这种情况下，我们需要通过确切地告诉注入器我们想要注入的内容来帮助注入器。

定义构造函数参数的类名

让我们看看如何为具有构造函数签名中非具体类型提示的类提供支持。考虑以下代码，其中 Car 需要一个 Engine，而 Engine 是一个接口

<?php
interface Engine {}

class V8 implements Engine {}

class Car {
    private $engine;
    public function __construct(Engine $engine) {
        $this->engine = $engine;
    }
}

在这种情况下，要实例化 Car，我们只需要提前定义一个类注入定义

<?php
$injector = new Auryn\Injector;
$injector->define('Car', ['engine' => 'V8']);
$car = $injector->make('Car');

var_dump($car instanceof Car); // true

以下是最重要的几点：

  1. 自定义定义是一个 array，其键与构造函数参数名称匹配
  2. 定义数组中的值表示要注入指定参数键的类名

因为我们需要定义的 Car 构造函数参数名为 $engine，所以我们的定义指定了一个名为 engine 的键，其值为我们想要注入的类名（V8）

自定义注入定义只在每个参数的基础上是必要的。例如，在以下类中，我们只需要定义 $arg2 的可注入类，因为 $arg1 指定了具体的类类型提示

<?php
class MyClass {
    private $arg1;
    private $arg2;
    public function __construct(SomeConcreteClass $arg1, SomeInterface $arg2) {
        $this->arg1 = $arg1;
        $this->arg2 = $arg2;
    }
}

$injector = new Auryn\Injector;
$injector->define('MyClass', ['arg2' => 'SomeImplementationClass']);

$myObj = $injector->make('MyClass');

注意：在类型提示抽象类时注入实例与上述接口类型提示的示例工作方式完全相同。

在注入定义中使用现有实例

注入定义还可以指定所需的类的一个预存在的实例，而不是字符串类名

<?php
interface SomeInterface {}

class SomeImplementation implements SomeInterface {}

class MyClass {
    private $dependency;
    public function __construct(SomeInterface $dependency) {
        $this->dependency = $dependency;
    }
}

$injector = new Auryn\Injector;
$dependencyInstance = new SomeImplementation;
$injector->define('MyClass', [':dependency' => $dependencyInstance]);

$myObj = $injector->make('MyClass');

var_dump($myObj instanceof MyClass); // true

注意：由于此 define() 调用传递的是原始值（如冒号 : 使用所示），您可以通过省略数组键并依赖于参数顺序而不是名称来实现相同的结果。如下所示：$injector->define('MyClass', [$dependencyInstance]);

动态指定注入定义

您还可以使用 Auryn\Injector::make 在调用时指定注入定义

<?php
interface SomeInterface {}

class SomeImplementationClass implements SomeInterface {}

class MyClass {
    private $dependency;
    public function __construct(SomeInterface $dependency) {
        $this->dependency = $dependency;
    }
}

$injector = new Auryn\Injector;
$myObj = $injector->make('MyClass', ['dependency' => 'SomeImplementationClass']);

var_dump($myObj instanceof MyClass); // true

上面的代码显示了即使我们没有调用注入器的 define 方法，调用时指定也允许我们实例化 MyClass。

注意：即席实例化定义将覆盖预定义的指定类的定义，但仅限于对Auryn\Injector::make的特定调用上下文中。

类型提示别名

面向接口是面向对象设计（OOD）中最有用的概念之一，设计良好的代码应尽可能类型提示接口。但这是否意味着我们必须为应用程序中的每个类分配注入定义，以获得抽象依赖关系的优势？幸运的是，这个问题的答案是“不”。注入器通过接受“别名”来满足这个目标。考虑以下示例：

<?php
interface Engine {}
class V8 implements Engine {}
class Car {
    private $engine;
    public function __construct(Engine $engine) {
        $this->engine = $engine;
    }
}

$injector = new Auryn\Injector;

// Tell the Injector class to inject an instance of V8 any time
// it encounters an Engine type-hint
$injector->alias('Engine', 'V8');

$car = $injector->make('Car');
var_dump($car instanceof Car); // bool(true)

在这个示例中，我们展示了如何为特定接口或抽象类类型提示的任何出现指定别名类。一旦分配了实现，注入器将使用它为任何具有匹配类型提示的参数提供支持。

重要：如果为实施分配覆盖的参数定义了注入定义，则定义优先于实施。

非类参数

所有之前的示例都展示了注入器类如何根据类型提示、类名定义和现有实例实例化参数。但是，如果我们想将标量或其他非对象变量注入到类中会发生什么？首先，让我们确定以下行为规则：

重要：注入器默认将所有命名参数定义视为类名。

如果您想让注入器将命名参数定义视为“原始”值而不是类名，您必须在定义中用冒号字符：作为参数名称的前缀。例如，考虑以下代码，我们告诉注入器共享一个PDO数据库连接实例，并定义其标量构造函数参数：

<?php
$injector = new Auryn\Injector;
$injector->share('PDO');
$injector->define('PDO', [
    ':dsn' => 'mysql:dbname=testdb;host=127.0.0.1',
    ':username' => 'dbuser',
    ':passwd' => 'dbpass'
]);

$db = $injector->make('PDO');

参数名称前面的冒号字符告诉注入器相关值“不是”类名。如果省略了上面的冒号，auryn将尝试实例化指定在字符串中的类名，并引发异常。此外，请注意，我们可以在上面的定义中指定数组、整数或任何其他数据类型。只要参数名称前面有：前缀，auryn就会直接注入值，而不会尝试实例化它。

注意：如前所述，由于这个define()调用传递的是原始值，您可以选择按参数顺序分配值，而不是按名称。由于PDO的前三个参数是$dsn、$username和$password，顺序如下，您可以通过省略数组键来完成相同的结果：$injector->define('PDO', ['mysql:dbname=testdb;host=127.0.0.1', 'dbuser', 'dbpass']);

全局参数定义

有时应用程序可能需要在每个地方重用相同的值。然而，在应用程序中可能使用的每个地方手动指定此类定义可能很麻烦。auryn通过公开Injector::defineParam()方法来减轻这个问题。考虑以下示例...

<?php
$myUniversalValue = 42;

class MyClass {
    public $myValue;
    public function __construct($myValue) {
        $this->myValue = $myValue;
    }
}

$injector = new Auryn\Injector;
$injector->defineParam('myValue', $myUniversalValue);
$obj = $injector->make('MyClass');
var_dump($obj->myValue === 42); // bool(true)

由于我们为myValue指定了全局定义，所有不是以下方式定义（如下）且匹配指定参数名称的参数都会自动填充全局值。如果参数符合以下任何标准，则不使用全局值：

  • 类型提示
  • 预定义的注入定义
  • 自定义调用时间定义

高级用法

实例共享

现代面向对象编程中更为普遍的弊端之一是Singleton反模式。寻求限制类为单个实例的编码人员往往陷入使用static Singleton实现的陷阱，例如配置类和数据库连接。虽然通常需要防止类的多个实例，但Singleton方法会导致测试性死亡，通常应避免使用。Auryn\Injector使得在上下文中共享类实例变得微不足道，同时允许最大的测试性和API透明度。

让我们看看如何使用auryn将您的应用程序连接起来，从而轻松解决面向对象的Web应用程序中常见的典型问题。在这里，我们希望在一个应用程序的多个层次之间注入一个单一的数据库连接实例。我们有一个控制器类，它请求一个需要PDO数据库连接实例的DataMapper。

<?php
class DataMapper {
    private $pdo;
    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
    }
}

class MyController {
    private $mapper;
    public function __construct(DataMapper $mapper) {
        $this->mapper = $mapper;
    }
}

$db = new PDO('mysql:host=localhost;dbname=mydb', 'user', 'pass');

$injector = new Auryn\Injector;
$injector->share($db);

$myController = $injector->make('MyController');

在上面的代码中，DataMapper实例将使用我们最初共享的相同的PDO数据库连接实例进行配置。这个例子虽然构造得过于简单，但其含义应该是清晰的。

通过共享一个类的实例，Auryn\Injector在配置具有该共享类类型提示的类时，总是会使用该实例。

一个更简单的例子

让我们看看一个简单的概念验证示例

<?php
class Person {
    public $name = 'John Snow';
}

$injector = new Auryn\Injector;
$injector->share('Person');

$person = $injector->make('Person');
var_dump($person->name); // John Snow

$person->name = 'Arya Stark';

$anotherPerson = $injector->make('Person');
var_dump($anotherPerson->name); // Arya Stark
var_dump($person === $anotherPerson); // bool(true) because it's the same instance!

将对象定义为共享将存储在注入器的共享缓存中的配置实例，并且所有未来的请求注入器提供该类的注入实例都将返回最初创建的对象。请注意，在上面的代码中，我们共享了类名（Person）而不是实际实例。共享既可以用类名，也可以用类的实例。区别在于，当您指定类名时，注入器将在第一次被要求创建它时缓存共享实例。

注意：一旦注入器缓存了共享实例，传递给Auryn\Injector::make的调用时定义将没有任何效果。一旦共享，实例将始终返回其类型的实例，直到对象取消共享或刷新。

实例化代理

通常，工厂类/方法用于在实例化后准备对象使用。auryn允许您通过在每个类的基础上指定可调用实例化代理来直接将工厂和构建器集成到注入过程中。让我们通过一个基本示例来演示注入代理的概念。

<?php
class MyComplexClass {
    public $verification = false;
    public function doSomethingAfterInstantiation() {
        $this->verification = true;
    }
}

$complexClassFactory = function() {
    $obj = new MyComplexClass;
    $obj->doSomethingAfterInstantiation();

    return $obj;
};

$injector = new Auryn\Injector;
$injector->delegate('MyComplexClass', $complexClassFactory);

$obj = $injector->make('MyComplexClass');
var_dump($obj->verification); // bool(true)

在上面的代码中，我们将MyComplexClass类的实例化委托给了闭包$complexClassFactory。一旦进行了这种委托，注入器在要求实例化MyComplexClass时将返回指定的闭包的结果。

可用的代理类型

任何有效的PHP可调用都可以使用Auryn\Injector::delegate注册为类实例化代理。此外，您可以指定指定一个具有__invoke方法的代理类名称，它将在委托时间自动配置并调用其__invoke方法。还可以使用['NonStaticClassName', 'factoryMethod']构造指定未实例化类的实例方法。例如

<?php
class SomeClassWithDelegatedInstantiation {
    public $value = 0;
}
class SomeFactoryDependency {}
class MyFactory {
    private $dependency;
    function __construct(SomeFactoryDependency $dep) {
        $this->dependency = $dep;
    }
    function __invoke() {
        $obj = new SomeClassWithDelegatedInstantiation;
        $obj->value = 1;
        return $obj;
    }
    function factoryMethod() {
        $obj = new SomeClassWithDelegatedInstantiation;
        $obj->value = 2;
        return $obj;
    }
}

// Works because MyFactory specifies a magic __invoke method
$injector->delegate('SomeClassWithDelegatedInstantiation', 'MyFactory');
$obj = $injector->make('SomeClassWithDelegatedInstantiation');
var_dump($obj->value); // int(1)

// This also works
$injector->delegate('SomeClassWithDelegatedInstantiation', 'MyFactory::factoryMethod');
$obj = $injector->make('SomeClassWithDelegatedInstantiation');
$obj = $injector->make('SomeClassWithDelegatedInstantiation');
var_dump($obj->value); // int(2)

准备和设置器注入

构造函数注入几乎总是比设置器注入更可取。然而，一些API需要额外的实例化后突变。auryn通过其Injector::prepare()方法适应这些用例。用户可以为任何类或接口名称注册后实例化修改。考虑

<?php

class MyClass {
    public $myProperty = 0;
}

$injector->prepare('MyClass', function($myObj, $injector) {
    $myObj->myProperty = 42;
});

$myObj = $injector->make('MyClass');
var_dump($myObj->myProperty); // int(42)

虽然上面的例子是构造的，但其用途应该是明显的。

注入以执行

除了使用构造函数提供类实例外，auryn还可以递归实例化任何有效的PHP可调用的参数。以下所有示例都有效

<?php
$injector = new Auryn\Injector;
$injector->execute(function(){});
$injector->execute([$objectInstance, 'methodName']);
$injector->execute('globalFunctionName');
$injector->execute('MyStaticClass::myStaticMethod');
$injector->execute(['MyStaticClass', 'myStaticMethod']);
$injector->execute(['MyChildStaticClass', 'parent::myStaticMethod']);
$injector->execute('ClassThatHasMagicInvoke');
$injector->execute($instanceOfClassThatHasMagicInvoke);
$injector->execute('MyClass::myInstanceMethod');

此外，您还可以传递一个类名给非静态方法，注入器将在提供和调用指定方法之前自动提供该类的实例（受注入器已存储的任何定义或共享实例的约束）

<?php
class Dependency {}
class AnotherDependency {}
class Example {
    function __construct(Dependency $dep){}
    function myMethod(AnotherDependency $arg1, $arg2) {
        return $arg2;
    }
}

$injector = new Auryn\Injector;

// outputs: int(42)
var_dump($injector->execute('Example::myMethod', $args = [':arg2' => 42]));

依赖解析

Auryn\Injector按以下顺序解决依赖关系

  1. 如果针对该类的共享实例存在，则始终返回共享实例
  2. 如果为类分配了代理可调用，则其返回结果将始终使用
  3. 如果传递给Auryn\Injector::make的调用时定义，则使用该定义
  4. 如果存在预定义的定义，则使用它
  5. 如果依赖项具有类型提示，则注入器将递归实例化它，受任何实现或定义的约束
  6. 如果没有类型提示，并且参数具有默认值，则注入默认值
  7. 如果定义了全局参数值，则使用该值
  8. 抛出异常，因为你做了愚蠢的事情

示例用例

依赖注入容器（DIC）在PHP社区中通常被误解。主要原因之一是主流应用程序框架中对这些容器的误用。通常，这些框架将它们的DIC扭曲成服务定位器反模式。这是件遗憾的事，因为一个好的DIC应该完全不同于服务定位器。

auryn 不是服务定位器！

使用DIC连接应用程序与将DIC作为依赖传递给对象（服务定位器）之间存在着巨大的差异。服务定位器（SL）是一种反模式——它隐藏类依赖关系，使代码难以维护，并使你的API成为谎言。

当你将SL传递给你的构造函数时，这使得确定类依赖关系变得困难。一个House对象依赖于Door和Window对象。无论ServiceLocator是否能够提供Door和Window对象，House对象都不会依赖于ServiceLocator的实例。

在现实生活中，你不会把整个建材店（希望如此）搬到建筑工地来，以便可以访问你需要任何部分。相反，工头（__construct()）会要求所需的具体部件（Door和Window），并着手获取它们。你的对象应该以同样的方式工作；它们应该只要求完成工作所需的具体依赖项。给House访问整个建材店，至多是不良的OOP风格，最坏的是维护噩梦。这里的关键是

重要：不要像服务定位器一样使用auryn！

避免邪恶的单例

在Web应用程序中，限制数据库连接实例的数量是一个常见的难题。每次我们需要与数据库通信时打开新的连接既浪费又慢。不幸的是，使用单例来限制这些实例会使代码脆弱且难以测试。让我们看看如何使用auryn在整个应用程序范围内注入相同的PDO实例。

假设我们有一个需要两个不同的数据映射器将信息持久化到数据库的服务类

<?php

class HouseMapper {
    private $pdo;
    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
    }
    public function find($houseId) {
        $query = 'SELECT * FROM houses WHERE houseId = :houseId';

        $stmt = $this->pdo->prepare($query);
        $stmt->bindValue(':houseId', $houseId);

        $stmt->setFetchMode(PDO::FETCH_CLASS, 'Model\\Entities\\House');
        $stmt->execute();
        $house = $stmt->fetch(PDO::FETCH_CLASS);

        if (false === $house) {
            throw new RecordNotFoundException(
                'No houses exist for the specified ID'
            );
        }

        return $house;
    }

    // more data mapper methods here ...
}

class PersonMapper {
    private $pdo;
    public function __construct(PDO $pdo) {
        $this->pdo = $pdo;
    }
    // data mapper methods here
}

class SomeService {
    private $houseMapper;
    private $personMapper;
    public function __construct(HouseMapper $hm, PersonMapper $pm) {
        $this->houseMapper = $hm;
        $this->personMapper = $pm;
    }
    public function doSomething() {
        // do something with the mappers
    }
}

在我们的连接/引导代码中，我们只需实例化一次PDO实例，并在Injector上下文中共享它

<?php
$pdo = new PDO('sqlite:some_sqlite_file.db');
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

$injector = new Auryn\Injector;

$injector->share($pdo);
$mapper = $injector->make('SomeService');

在上面的代码中，DIC实例化了我们的服务类。更重要的是，它为这样做生成的数据映射器类都使用我们最初共享的数据库连接实例进行了注入。

当然，我们不必手动实例化我们的PDO实例。我们也可以在容器中注入一个创建PDO对象的定义，让它为我们处理

<?php
$injector->define('PDO', [
    ':dsn' => 'sqlite:some_sqlite_file.db'
]);
$injector->share('PDO');
$service = $injector->make('SomeService');

在上面的代码中，注入器会将字符串定义作为$dsn参数传递给PDO::__construct方法，并在需要实例化需要PDO实例的类时自动生成共享的PDO实例。

应用程序引导

DIC应该用于将应用程序的不同对象连接成一个统一的、功能性的单元（通常在引导或前端控制器阶段）。这种用法为面向对象（OO）Web应用程序中的一个棘手问题提供了一个优雅的解决方案：在依赖关系未知的情况下如何实例化类。

考虑以下前端控制器代码，其任务是

  1. 加载应用程序路由列表并将它们传递给路由器
  2. 生成客户端HTTP请求的模型
  3. 根据应用程序的路由列表对请求实例进行路由
  4. 实例化路由控制器并调用与HTTP请求适当的方法
<?php

define('CONTROLLER_ROUTES', '/hard/path/to/routes.xml');

$routeLoader = new RouteLoader();
$routes = $routeLoader->loadFromXml(CONTROLLER_ROUTES);
$router = new Router($routes);

$requestDetector = new RequestDetector();
$request = $requestDetector->detectFromSuperglobal($_SERVER);

$requestUri = $request->getUri();
$requestMethod = strtolower($request->getMethod());

$injector = new Auryn\Injector;
$injector->share($request);

try {
    if (!$controllerClass = $router->route($requestUri, $requestMethod)) {
        throw new NoRouteMatchException();
    }

    $controller = $injector->make($controllerClass);
    $callableController = array($controller, $requestMethod);

    if (!is_callable($callableController)) {
        throw new MethodNotAllowedException();
    } else {
        $callableController();
    }

} catch (NoRouteMatchException $e) {
    // send 404 response
} catch (MethodNotAllowedException $e) {
    // send 405 response
} catch (Exception $e) {
    // send 500 response
}

在其他地方，我们有各种控制器类，每个类都请求它自己的依赖项。

<?php

class WidgetController {
    private $request;
    private $mapper;
    public function __construct(Request $request, WidgetDataMapper $mapper) {
        $this->request = $request;
        $this->mapper = $mapper;
    }
    public function get() {
        // do something for HTTP GET requests
    }
    public function post() {
        // do something for HTTP POST requests
    }
}

在上面的例子中，Auryn DIC 允许我们编写完全可测试的、完全面向对象的控制器，这些控制器请求它们的依赖项。由于 DIC 会递归地实例化它所创建的对象的依赖项，因此我们不需要传递服务定位器。此外，这个例子还展示了如何使用 auryn DIC 的共享功能来消除邪恶的单例。在前控制器代码中，我们共享请求对象，这样任何由 Auryn\Injector 实例化的、请求 Request 的类都将接收到相同的实例。这个功能不仅有助于消除单例，而且还有助于消除难以测试的 static 属性。