每种方法的优点/缺点是什么？我应该如何确定何时使用一个或另一个？
最后，为什么不使用两者？我可以创建引用一个接口的立面。看来Sentry 2是这样写的。有最好的做法吗
Facades不是依赖注入的替代品。
Laravel Facade是服务定位器模式的实现，创建一个干净漂亮的访问对象的方式：
MyClass::doSomething();
这是静态方法的PHP语法，但是Laravel改变了游戏，使它们在后台非静态，为您提供了一个漂亮，愉快和可测试的方式来编写应用程序。
依赖注射
依赖注入基本上是一种将参数传递给构造函数和方法的方法，同时自动分配它们。
class MyClass {
private $property;
public function __construct(MyOtherClass $property)
{
/// Here you can use the magic of Dependency Injection
$this->property = $property
/// $property already is an object of MyOtherClass
}
}
更好的构建它将使用您的依赖注入构造函数中的接口：
class MyClass {
private $property;
public function __construct(MyInterface $property)
{
/// Here you can use the magic of Dependency Injection
$this->property = $property
/// $property will receive an object of a concrete class that implements MyInterface
/// This class should be defined in Laravel elsewhere,but this is a way of also make
/// your application easy to maintain,because you can swap implementations of your interfaces
/// easily
}
}
但请注意，在Laravel中，您可以以相同的方式注入类和接口。要注入接口，你只需要告诉它，这将是这样的：
App::bind('MyInterface','MyOtherClass');
这将告诉Laravel，每当你的一个方法需要一个MyInterface的实例，它应该给它一个MyOtherClass。
这里发生的是这个派生体有一个“依赖性”：MyOtherClass，它将由Laravel使用IoC container自动注入。所以，当你创建一个MyClass的实例时，Laravel会自动创建一个MyOtherClass的实例并将其放在变量中$类。
依赖注入只是开发人员创建的一个奇怪的行话，就像“自动生成参数”一样简单。
何时使用一个或另一个？
正如你所看到的，它们是完全不同的，所以你不需要在它们之间决定，但你必须决定在应用程序的不同部分中与一个或另一个在哪里。
使用Facades轻松地编写代码。例如：为应用程序模块创建程序包是一个很好的做法，因此，为这些程序包创建Facades也是一种让他们看起来像一个Laravel公共类并使用静态语法访问它们的方法。
每次您的类需要使用数据或从另一个类处理时，请使用依赖注入。这将使您的代码可以测试，因为您将能够将这些依赖项的模拟“注入”到您的课堂中，您还将运用single responsibility原理(请查看SOLID principles)。
