Laravel 中的依赖注入和 IoC

概述Laravel 中的依赖注入和 IoC

作为开发者，我们一直在尝试通过使用设计模式和尝试新的健壮型框架来寻找新的方式来编写设计良好且健壮的代码。在本篇文章中，我们将通过 Laravel 的 IoC 组件探索依赖注入设计模式，并了解它如何改进我们的设计。

依赖注入

依赖注入一词是由 Martin Fowler 提出的术语，它是将组件注入到应用程序中的一种行为。就像 Ward Cunningham 说的:

依赖注入是敏捷架构中关键元素。

让我们看一个例子：

class UserProvIDer{    protected $connection;    public function __construct(){        $this->connection = new Connection;    }    public function retrIEveByCredentials( array $credentials ){        $user = $this->connection                        ->where( 'email', $credentials['email'])                        ->where( 'password', $credentials['password'])                        ->first();        return $user;    }}

如果你要测试或者维护这个类，你必须访问数据库的实例来进行一些查询。为了避免必须这样做，你可以将此类与其他类进行 解耦 ，你有三个选项之一，可以将 @H_403_28@Connection 类注入而不需要直接使用它。

将组件注入类时，可以使用以下三个选项之一：

构造方法注入

class UserProvIDer{    protected $connection;    public function __construct( Connection $con ){        $this->connection = $con;    }    ...

Setter 方法注入

同样，我们也可以使用 Setter 方法注入依赖关系：

class UserProvIDer{    protected $connection;    public function __construct(){        ...    }    public function setConnection( Connection $con ){        $this->connection = $con;    }    ...

接口注入

interface ConnectionInjector{    public function injectConnection( Connection $con );}class UserProvIDer implements ConnectionInjector{    protected $connection;    public function __construct(){        ...    }    public function injectConnection( Connection $con ){        $this->connection = $con;    }}

当一个类实现了我们的接口时，我们定义了 @H_403_28@injectConnection 方法来解决依赖关系。

优势

现在，当测试我们的类时，我们可以模拟依赖类并将其作为参数传递。每个类必须专注于一个特定的任务，而不应该关心解决它们的依赖性。这样，你将拥有一个更专注和可维护的应用程序。

如果你想了解更多关于 DI 的信息，Alejandro Gervassio 在 本系列 文章中对其进行了广泛而专业的介绍，所以一定要去读这些文章。那么，什么又是 IoC 呢？IoC （控制反转）不需要使用依赖注入，但它可以帮助你有效的管理依赖关系。

控制反转

Ioc 是一个简单的组件，可以更加方便地解析依赖项。你可以将对象形容为容器，并且每次解析类时，都会自动注入依赖项。

Laravel Ioc

当你请求一个对象时， Laravel Ioc 在解决依赖关系的方式上有些特殊：

我们使用一个简单的例子，将在本文中改进它。
@H_403_28@SimpleAuth 类依赖于 @H_403_28@fileSessionStorage ，所以我们的代码可能是这样的：

class fileSessionStorage{  public function __construct(){    session_start();  }  public function get( $key ){    return $_SESSION[$key];  }  public function set( $key, $value ){    $_SESSION[$key] = $value;  }}class SimpleAuth{  protected $session;  public function __construct(){    $this->session = new fileSessionStorage;  }}//创建一个 SimpleAuth$auth = new SimpleAuth();

这是一种经典的方法，让我们从使用构造函数注入开始。

class SimpleAuth{  protected $session;  public function __construct( fileSessionStorage $session ){    $this->session = $session;  }}

现在我们创建一个对象：

$auth = new SimpleAuth( new fileSessionStorage() );

现在我想使用 Laravel Ioc 来管理这一切。

因为 @H_403_28@Application 类继承自 @H_403_28@Container 类，所以你可以通过 @H_403_28@App 门面来访问容器。

App::bind( 'fileSessionStorage', function(){    return new fileSessionStorage;});

@H_403_28@bind 方法第一个参数是要绑定到容器的唯一 ID ，第二个参数是一个回调函数每当执行 @H_403_28@fileSessionStorage 类时执行，我们还可以传递一个表示类名的字符串，如下所示。

Note: 如果你查看 Laravel 包时，你将看到绑定有时会分组，比如（ @H_403_28@vIEw, @H_403_28@vIEw.finder……）。

假设我们将会话存储转换为 MysqL 存储，我们的类应该类似于：

class MysqLSessionStorage{  public function __construct(){    //...  }  public function get($key){    // do something  }  public function set( $key, $value ){    // do something  }}

现在我们已经更改了依赖项，我们还需要更改 @H_403_28@SimpleAuth 构造函数，并将新对象绑定到容器中！

高级模块不应该依赖于低级模块，两者都应该依赖于抽象对象。
抽象不应该依赖于细节，细节应该取决于抽象。

Robert C. Martin

我们的 @H_403_28@SimpleAuth 类不应该关心我们的存储是如何完成的，相反它更应该关注于消费的服务。

因此，我们可以抽象实现我们的存储：

interface SessionStorage{  public function get( $key );  public function set( $key, $value );}

这样我们就可以实现并请求 @H_403_28@SessionStorage 接口的实例：

class fileSessionStorage implements SessionStorage{  public function __construct(){    //...  }  public function get( $key ){    //...  }  public function set( $key, $value ){    //...  }}class MysqLSessionStorage implements SessionStorage{  public function __construct(){    //...  }  public function get( $key ){    //...  }  public function set( $key, $value ){    //...  }}class SimpleAuth{  protected $session;  public function __construct( SessionStorage $session ){    $this->session = $session;  }}

如果我们使用 @H_403_28@App::make('SimpleAuth') 通过容器解析 @H_403_28@SimpleAuth
类，容器将会抛出 @H_403_28@BindingResolutionException ，尝试从绑定解析类之后，返回到反射方法并解析所有依赖项。

Uncaught exception 'Illuminate\Container\BindingResolutionException' with message 'Target [SessionStorage] is not instantiable.'

容器正试图将接口实例化。我们可以为该接口做一个具体的绑定。

App:bind( 'SessionStorage', 'MysqLSessionStorage' );

现在每次我们尝试从容器解析该接口时，我们会得到一个 @H_403_28@MysqLSessionStorage 实例。如果我们想要切换我们的存储服务，我们只要变更一下这个绑定。

Note: 如果你想要查看一个类是否已经在容器中被绑定，你可以使用 @H_403_28@App::bound('Classname') ，或者可以使用 @H_403_28@App::bindIf('Classname') 来注册一个还未被注册过的绑定。

Laravel Ioc 也提供 @H_403_28@App::singleton('Classname', 'resolver') 来处理单例的绑定。
你也可以使用 @H_403_28@App::instance('Classname', 'instance') 来创建单例的绑定。
如果容器不能解析依赖项就会抛出 @H_403_28@ReflectionException ，但是我们可以使用 @H_403_28@App::resolvingAny(Closure) 方法以回调函数的形式来解析任何指定的类型。

Note: 如果你为某个类型已经注册了一个解析方式 @H_403_28@resolvingAny 方法仍然会被调用，但它会直接返回 @H_403_28@bind 方法的返回值。

小贴士这些绑定写在哪儿：
如果只是一个小型应用你可以写在一个全局的起始文件 @H_403_28@global/start.PHP 中，但如果项目变得越来越庞大就有必要使用 Service ProvIDer 。测试：
当需要快速简易的测试可以考虑使用 @H_403_28@PHP artisan tinker ，它十分强大，且能帮你提升你的 Laravel 测试流程。Reflection API：
PHP 的 Reflection API 是非常强大的，如果你想要深入 Laravel Ioc 你需要熟悉 Reflection API ，可以先看下这个 教程 来获得更多的信息。最后

和往常一样，学习或者了解某些东西最好的方法就是查看源代码。Laravel Ioc 仅仅只是一个文件，不会花费你太多时间来完成所有功能。你想了解更多关于 Laravel Ioc 或者 Ioc 的一般情况吗？那请告诉我们吧！

推荐教程：《Laravel教程》 总结

以上是内存溢出为你收集整理的Laravel 中的依赖注入和 IoC全部内容，希望文章能够帮你解决Laravel 中的依赖注入和 IoC所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。