最近看了很多关于依赖注入(inject)的书，理论上讲了很多道理。拥有易于测试、单一责任类的想法听起来很聪明。但是，我正在为要走多远而苦苦挣扎。

我现在正在开发一个 PHP Web 应用程序，它有一个 CMS 组件并且主要由数据库驱动。在 CMS 中，您可以创建页面，页面本身是使用各种小部件构建的。小部件可以是纯 HTML(来自所见即所得编辑器)，也可以更复杂一些，例如照片库。这是重要的部分，照片库小部件依赖于其他数据库模型，如 PhotoGallery 和 PhotoGalleryImages 才能正常运行。

根据 Miško Hevery ，我不应该通过应用程序的不同层传递对依赖项的引用。相反，每个类应该简单地“请求”它需要的任何依赖项。使用他的示例，这就是它的样子:

$db = new Database()
$repo = new UserRepository($db);
$page = new LoginPage($repo);

虽然我可以看到这对我的应用程序的服务层工作得很好，但我真的不明白这如何与我的值(value)对象/实体一起工作。在我看来，这种模式要求我在应用程序的最高层实例化所有模型。但是，当我需要页面类来告诉我需要实例化哪些小部件时，我如何才能在该级别实例化所有小部件？在不知道我正在创建什么小部件的情况下，我怎么知道需要创建和注入(inject)哪些小部件依赖项？

理论上，DI 对我来说很有意义。然而，事实证明，在我的新 Web 应用程序中实际实现此模式更加困难。关于 DI 和 IoC，我还缺少什么吗？谢谢!

更新:对坦度的回应

非常感谢 Tandu 的回复。我认为 DI 实际上可能不是我的问题，因为我认为我非常清楚它是什么，无论是构造函数还是 setter 注入(inject)，或者是使用容器还是穷人的方式来完成。我确实认为正在发生的事情是 DI 正在挑战我重新思考我目前的编程方式。我认为我的 OOP 设计是问题所在。为了说明这一点，这里是我通常如何编写这个问题:

class Page
{
    public $id;
    public $name;

    public function widgets()
    {
        // Perform SQL query to select all widgets
        // for this page from the database, and then
        // return them as Widget objects.
    }
}

interface Widget
{
    public $id;
    public $page_id;
    public $type;

    public function widgetize();
}

class PhotoGallery_Widget implements Widget
{
    public $id;
    public $page_id;
    public $type;

    public function widgetize()
    {
        $gallery = new Photogallery();

        foreach($gallery->images())
        {
            // Create gallery HTML code
        }
    }
}

// Finally, to create the page, I would:
$page = new Page(1);
foreach($page->widgets() as $widget)
{
    $widget->widgetize();
}

显然这里存在一些问题。 Page 模型依赖于 Widget 模型。 PhotoGallery_Widget 模型依赖于 PhotoGallery 模型，甚至 PhotoGallery 模型还依赖于 PhotoGalleryImages 模型。问题是，以这种方式开发对我来说效果很好。随着我对应用程序的层越来越深入，每一层都承担了创建它需要的对象的责任。引入 DI 对我的思维方式产生了重大影响。但是，我想学习如何正确地做到这一点。仅仅因为这现在对我有用，并不意味着我应该继续这样做。

您提到使用工厂。但是，工厂实际上不会破坏 DI，因为它们正在实例化对象吗？

您可能还会注意到我的模型负责与数据库交互。我怀疑这也是我设计的问题。我是否应该使用某种数据映射来从我的模型中消除这种责任？

鉴于我目前如何实现我的代码的这个更具体的例子，你有任何其他建议或者你能进一步说明我应该如何以不同的方式来做吗？

最佳答案

如果不查看具体的实现，就很难给出具体的建议，所以我会提供我能提供的一般性建议(实际上我不是很好)。听起来您可以使用“依赖项注入(inject)容器”(google it .. 找到您喜欢的或根据您的目的自己滚动)来管理类的大型互锁依赖项。

您应该记住的一件事是，您的代码应该轻轻地落在设计周围，这将非常牢固地支撑它。您不必努力让您的代码遵循您创建的设计。如果您尝试做的事情无法按照您对设计的理解进行工作，那么可能是时候重写了。

您也只使用构造函数注入(inject)的示例。我相信您知道可以在适当的时候使用其他类型的注入(inject)，例如 setter 注入(inject)。

正如我所说，我没有看到您的代码，但您的设计存在问题，页面不应该知道它需要什么小部件，而应该知道服务。如果您将特定的小部件实现绑定(bind)到页面，这将违反依赖倒置(并使依赖注入(inject)更加困难)。相反，您的代码应该更符合以下内容:

interface Widget {
   function widgetize();
}

class ConcretePage {
   private $widgets = array();

   public function addWidget(Widget $widget) {
      $this->widgets[] = $widget;
   }

   public function run() {
      foreach ($this->widgets as $widget) {
         $widget->widgetize();
      }
   }
}

该服务将创建一个页面并添加它需要的小部件。该页面不应该关心那些小部件。您可能还必须在页面和小部件之间实现一个桥梁。该服务也可以处理。

作为您提到的文章作者 states here ，您应该拥有专门用于构建整个对象图的代码(这是所有 new 运算符所在的位置)。想象一下，在没有这些小部件的类定义的情况下测试需要五个特定小部件的页面会有多困难!您需要依赖抽象。

这可能不符合 DI 的精神，但更简单的解决方案是拥有一个 WidgetFactory:

class Page {
    private $wf;
    private $widgets = array('whiz', 'bang');
    public function __construct(WidgetFactory $wf) {
       $this->wf = $wf;
    }
    public function widgetize() {
       foreach ($this->widgets as $widget) {
          $widget = $this->wf::build($widget);
       }
    }
}

WidgetFactory 接口(interface)可以从应用程序到应用程序甚至在测试中分开。这仍然为您提供了 Page 期望的小部件的某种抽象级别。

关于php - 在 PHP Web 应用程序中使用依赖注入(inject)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7910966/