Laravel 5包中的依赖项注入是否使用

我正在为Laravel 5开发一个包，在使用Laravel的核心类时，我决定从包中的依赖注入中获益，但在阅读了更多内容并提出了这个问题之后

现在我想到了一个想法，如果我们使用

Facades

这么多，调用静态方法，比如

FaceadeName:nameOfMethod

容器实际上为我们创建了一个对象并调用了它的方法，因此，在某种程度上，对类使用依赖项注入（也可通过Facades获得）几乎是无用的

例如，拥有该类：

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');           
 }
}

这样做：

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

然后在函数中：

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

它几乎是无用的，因为我们将一些东西绑定到已经绑定在那里的容器上

将

myFunction

更改为

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

同样，它可能看起来像方法注入，但并没有带来太多优势。因此，对于Laravel中的

外观

，最好不要使用

依赖注入

。

---

请让我知道我是否正确，如果我错了，请用正确的答案论证我的观点。

Facades提供了一种通过类访问容器的方法，因此当您访问

\Lang:：function（）

时，您实际上是在调用

应用程序（'translator'）->function（）。因此，在上面的示例中，当您将
Lang
facade绑定到容器中时，您需要将它绑定两次，这并不是您想要的

Laravel的所有功能都已绑定到容器中，可以通过调用
app（'object'）
进行访问。您可以在这里看到所有绑定

对于依赖注入，您不应该尝试注入facades，而是注入facades已经引用的类。例如，
\Lang
facade引用了
illighted\Translation\Translator
，它作为
Translator
绑定到容器

在你的课堂上，你可以做到以下几点

use App\Http\Controllers\Controller;
use Illuminate\Translation\Translator;

class MyController extends Controller
{
    protected $translator;

    // Dependency injection example
    public function __construct(Translator $translator)
    {
        $this->translator = $translator;
    }

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

    // Method injection example
    public function myFunction(Translator $translator)
    {
        $text = $translator->get('package::all.text1');
    }
}

Facades提供了一种通过类访问容器的方法，因此当您访问
\Lang:：function（）
时，实际上是在调用
app（'translator'）->function（）
。因此，在上面的示例中，当您将
Lang
facade绑定到容器中时，您需要将它绑定两次，这并不是您想要的

Laravel的所有功能都已绑定到容器中，可以通过调用
app（'object'）
进行访问。您可以在这里看到所有绑定

对于依赖注入，您不应该尝试注入facades，而是注入facades已经引用的类。例如，
\Lang
facade引用了
illighted\Translation\Translator
，它作为
Translator
绑定到容器

在你的课堂上，你可以做到以下几点

use App\Http\Controllers\Controller;
use Illuminate\Translation\Translator;

class MyController extends Controller
{
    protected $translator;

    // Dependency injection example
    public function __construct(Translator $translator)
    {
        $this->translator = $translator;
    }

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

    // Method injection example
    public function myFunction(Translator $translator)
    {
        $text = $translator->get('package::all.text1');
    }
}

+为班级注入1。除其他外，它使测试
myFunction（）
和插入模拟
转换器
变得更加容易。感谢您的回答，考虑到您的答案，这种方法是否有足够的优势坚持使用它，并使用这样的核心类而不是使用
Facades
，例如，它是否有助于测试或任何其他可能的优势？（我知道这几乎是一个新问题）使用依赖注入使测试更容易，因为您可以将模拟对象直接传递到类和/或函数中。这还允许您将层从控制器中抽象出来，这使得您的代码不再依赖于框架，如果您将来希望迁移的话（存储库模式就是一个很好的例子）+1注入类。除其他外，它使测试
myFunction（）
和插入模拟
转换器
变得更加容易。感谢您的回答，考虑到您的答案，这种方法是否有足够的优势坚持使用它，并使用这样的核心类而不是使用
Facades
，例如，它是否有助于测试或任何其他可能的优势？（我知道这几乎是一个新问题）使用依赖注入使测试更容易，因为您可以将模拟对象直接传递到类和/或函数中。这还允许您将层从控制器中抽象出来，这使得您的代码在将来需要迁移时不再依赖于框架（存储库模式就是一个很好的例子）