在Laravel中，使用App::make('')而不是构造函数注入有什么缺点吗?

您的方法有一个缺点，执行您所建议的将使您的应用程序的可测试性降低。

我的意思是，如果你试图为父类编写单元测试，你将不再孤立地测试父类。您的测试现在还依赖于父类内部声明的依赖项的结果。

如果你通过构造函数注入(或任何类型的注入)传入这个依赖，你就可以控制这个依赖，并且可以模拟/存根它的输出，更好地隔离测试你的父类。

首先，使用App::make('...')或app('...')没有缺点，但是如果你在构造函数中使用类型提示，那么你就不需要手动注入依赖项。例如，如果您有这样的内容:

class SomeController extends BaseController {
    protected $otherClass = null;
    public function __construct(SomeOtherClass $otherClass)
    {
        $this->otherClass = $otherClass;
    }
}

现在，如果你使用SomeController类，那么Laravel会自动将SomeOtherClass注入SomeController类，如果你的SomeOtherClass有自己的依赖项，那么Laravel也会注入这些，如果它们是类型提示。因此，您可以在构造函数中使用Dependency Injection而不是App::make(...)/app(...)，如果您使用Interface而不是concrete class来键入提示会更好。上面说过，在interface而不是implementation(具体类)上编程。

一般来说，在依赖注入技术中有一件事，那就是，当您将class与其他对象组合在一起时，它可能看起来很复杂。实际上，依赖注入是一种通过runtime方法通过constructor方法混合其他对象来组合类的方法(组合优于继承)，但如果有如此多的依赖，有时找出对象之间的关系可能看起来很复杂。最终，这是一个很好的设计模式，它为我们提供了一种将对象彼此解耦的方法，您需要明智地选择何时使用它。

Update:实际上，在Laravel中，当您在构造函数方法中键入提示dependency时，framework通过读取其依赖对象的type自动注入依赖项，而在幕后，Laravel使用App::make(...)方法。所以，如果你不使用依赖注入，那么你只需要手动使用App::make(...)，这就是全部。在这两种情况下，框架或开发人员都会自动使用App::make()。因此，请毫不犹豫地使用App::make()，它是安全的，也是一种更好的解耦依赖关系的方法。

换句话说，如果你在构造函数方法中输入hint，那么Laravel将使用App::make(...)自动注入它们，但如果你不输入hint，那么你需要手动注入它们，在这种情况下，你将使用App::make()而不是框架，就是这样。对于依赖的自动解析，你需要提示你的依赖，但如果你手动注入你的依赖，你不需要提示它们，没有类型提示，Laravel不能自动注入任何依赖，这是有意义的。顺便说一句，我不是在想testing。