Question

通常我会通过构造函数注入依赖项，但是当父类具有依赖项并且必须将它们传递给所有子项时，它会变得非常冗长。

另一种方法是仅在父类中使用$this->dependancy = App::make('Dependancy')。然后父和子构造函数都可以为空。这样做有什么缺点吗？

Answer 1

您的方法有一个缺点，做您的建议将使您的应用程序不易测试。

我的意思是，如果您尝试为父类编写单元测试，您将不再孤立地测试该父类。您的测试现在还取决于父类中声明的依赖项的结果。

如果通过构造函数注入（或任何类型的注入）传递此依赖项，则可以控制依赖项，并可以模拟/存储它的输出，并更好地单独测试父类。

Answer 2

首先，使用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方法中混合其他对象来组成一个类的方法（组合而不是继承），但有时候如果找到对象与对象的关系可能看起来很复杂有这么多的依赖。最终它是一个很好的设计模式，它为我们提供了一种方法来将对象彼此分离，你需要明智地选择何时使用它。

更新：实际上，在Laravel中，当您在构造函数方法中键入提示dependency时，framework会通过读取{type自动注入依赖项。 1}}它的依赖对象在场景后面，Laravel使用App::make(...)方法。因此，如果您不使用依赖注入，那么您只需手动使用App::make(...)即可。在这两种情况下，框架或开发人员都会自动使用App::make()。因此，毫不犹豫地使用App::make()，这是一种安全的方法，可以更好地将依赖关系相互分离。

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

在Laravel中，使用App :: make（＆＃39;＆＃39;）而不是构造函数注入的任何缺点？

2 个答案: