Laravel5软件包中依赖注入的最佳方法

我正在为Laravel 5开发一个包,现在我需要从依赖注入中受益,以获得更具可伸缩性和可靠性的应用程序,我不知道哪种方法最好采用,为什么,这是我的代码和我需要注入Lang类依赖项

 class MyController extends \App\Http\Controllers\Controller
 {        
    public $text;
    public $lang;

    public function __construct()
    {         
       // Some codes here                            
    }

    public function myFunction(){
       $this->text = \Lang::get('package::all.text1');           
     }
}

在这个链接http://laravel.com/docs/4.2/ioc建议2方法,Basic Usage并Automatic Resolution根据我的链接采取第一种方法我需要添加的理解

 App::bind('lang', function($app)
{
    return new \Lang();
 });    

到应用程序的寄存器部分然后在函数中我会有这样的事情:

 public function myFunction()
{
  $lang = \App::make('lang');       
  $this->text = $lang::get('package::all.text1');           
 }

另一种方法是修改之constructor类的

  public function __construct(Lang $lang)
  {         
      $this->lang = $lang;
  }

然后从类中实例化对象

  $myCOntroller= App::make('MyController');

哪种方式更好的方式,考虑到这class是一个Controller,它将在routes文件中调用,或者如果我对链接的理解不正确,请纠正我.还请告诉我为什么你建议任何这些方法.

应该注意的是,使用本地IoC分辨率($app->make()样式)并不比直接使用外观(Lang::get()样式)好多了 - 你仍然非常依赖Laravel的特定类,而没有真正使代码明确表明它需要这些精确的类.因此,如果您希望代码尽可能便携,那么一般建议是尽可能地为接口编写代码.

当然,目前在PHP开发中有一些很大的缺点:

通常不定义这些接口(PSR-3 LoggerInterface接口除外),因此您仍然必须依赖接口的特定实例(在本例中为Laravel).

如果您决定创建自己的通用接口(或者FIG最终会创建其中的一些),那么Laravel为翻译提供的类(例如)无论如何都不会实现它,因此您需要将现有的类子类化为仅看起来它实现了你自己的界面.但是,嘿,这是目前的最佳实践,所以我想如果你想使用当前的最佳实践,代码到接口,并且暂时不担心你编写的接口是特定于Laravel的.

但无论如何,这是我对你的具体问题的看法.首先,我应该说我还没有实际使用Laravel 5(只是4s),但我一直都在关注它的发展.

如果我编写的类将使用给定的依赖项,或者作为类的工作方式的核心部分,我将使用构造函数依赖注入.这里的示例是控制器中的Request或一些Repository类,或控制台命令类中的业务逻辑类.

如果我需要我只需要一个特定的目的(可能从控制器重定向并需要生成URI)我将从IoC容器($this->app->make())解析本地版本,然后使用它.如果我使用Laravel 5并且该方法被Laravel直接调用(例如控制器的动作方法),我可能会使用方法注入,我不是100%肯定.

最后要注意的是,一般的建议是,如果构造函数方法签名由于大量依赖性而变得太大:

现在是时候看看你的代码是否过分依赖外部依赖.也许你的类的一些功能可以被提取到它自己的类,它分裂两者之间的依赖关系.

您应该考虑使用setter方法而不是构造函数注入 - 所以不是接受Request对象,而是使用$class->setRequest()方法.这样做的缺点是你需要告诉Laravel的IoC容器如何实例化你的对象(即必须调用这些setter).这不是什么大不了的事情,而是值得注意的事情.

相关链接:

Laravel 5的IoC文章

Laravel 5的控制器注射建议