在PHP中什么时候需要依赖注入?


When is Dependency Injection necessary in PHP?

依赖注入(DI)对于拥有多个团队成员的大型企业应用程序更重要吗?现在我是一个开发人员,试图破解一个小网站,看看它是否获得牵引力。然而,我不相信DI会给我正在编写的代码增加价值,尽管这个社区提供了压倒性的支持。

我花了上周的时间研究DI并在我的代码中实现,这并不困难,只是很耗时。但是我仍然没有看到解耦和单元测试的好处。相反,它似乎使代码更难以理解,需要更长的时间来编写,并且可能存在性能问题。在我浪费更多的时间来实现DI之前,我对下面要解决的问题很感兴趣。

1)解耦的好处?我看不出DI如何降低代码的依赖性。代码本质上需要相互依赖才能正常工作。DI只是将这个依赖移到另一个你看不到它的地方。例如,假设我有一个方法调用另一个静态方法。

class User {
// Static Dependency //
function process_registration() {
    if(Form::validate($_POST['email'])) {
        Message::send_message("Registration Complete");
    }
}
// Dependency Injection //
function __construct($form, $message) {
    $this->form = $form;
    $this->message = $message;
}
function process_registration() {
    if($this->form->validate($_POST['email'])) {
        $this-message->send_message("Registration Complete");
    }
}
}

DI不会改变process_registrationFormMessage类的依赖。即使它们被注入到"用户"类的属性,难道process_registration 仍然依赖于的类属性的工作?此外,如果我有一个容器注入属性到"用户"类,难道方法依赖于容器实例化它的类?假设我将来将"process_registration"重构到另一个类中,或者在不同的项目中重用它。无论是否使用DI,该方法都将停止工作,因为相同的类属性和注入容器可能不存在。

2)代码可读性?从上面的示例中可以看到,process_registration方法所需的代码现在增加了一倍。如果考虑到每次实例化一个新类或每次修改一个类方法时都需要修改的Container类,则要增加一倍以上。除此之外,代码现在不那么直观了。$database$form$message等属性与User有什么关系?代码也不那么优雅。以前,我的静态方法是!Form::validate(),两个单词。现在是$this->form->validate(),长了30%。这影响了我注入到类中的所有方法。所以现在当我看一页代码,它是$this->, $this->, $this->重复了一百次,而不是静态方法,立即描述性的。而不是$user=new User($user_id);,现在是ioc::get('user')->newUser($user_id);。我的观点是DI鼓励使用非php标准惯用代码。

3)更好的性能?DI不是在方法准备好使用时及时调用它,而是鼓励对可能永远不会使用的对象进行实例化(例如,当验证失败或抛出错误时)。如果这些对象有巨大的库并且加载很重(例如PHPExcel),这可能是一个性能问题。这需要做多少功?

4)单元测试?代码测试对于中小型项目是必要的吗?现在,当我的代码有错误时,PHP会通知我。通过检查error_log,它们通常很容易定位和修复。如果我将来需要扩大项目规模,这是否会成为一个问题?如果没有,什么时候需要DI来进行测试?

基于以上原因,我发现没有必要在我的项目中实现DI。然而,我感兴趣的是何时何地有必要实施,这样我就可以适当地这样做。请给出你自己的详细例子并以推理支持。我对其他文章的链接不感兴趣,因为它们可能相当不清楚。提前感谢!

1)假设您想更改表单类名。如果你使用了DI,那么你只需要在一个地方做改变,当你在容器中注册Form类的时候。

使用DI进行单元测试更容易,因为你有解耦的组件。您可以分别测试User、Message和Form类。在你的例子中,你不能测试用户类也没有消息和表单类。

2)可读性与函数/可变长度无关。DI提高了可读性,因为通过查看构造函数,您可以清楚地看到在某些类中如何以及哪些依赖项被使用。

3)我不知道单个DIC不允许共享对象-只实例化一次并且在请求时(惰性加载)。

1.