php - ServiceLocator 和开放/封闭原则

Question

我愿意:

1. 使所有需要它们的类都可以看到通常需要的服务，
2. 使用最少的样板文件，并且
3. 不牺牲可测试性!

这是一个小项目，我认为 DI 可能有点矫枉过正，但也许我错了？反正我一直关注ServiceLocator pattern as described by Martin Fowler

在客户端类的构造函数中，我有这样的东西:

this->db = Locator::getDb();
this->log = Locator::getLogger();

然后类的其余方法通过这些成员属性访问服务，例如:

this->fooModel = new fooModel(this->db);
fooItem1234 = this->fooModel->findById(1234);

但是我也希望“模型”对象(如上面的 fooModel)具有这种级别的可见性，因为它们可以从多个不同的地方访问，并且不需要有多个实例。

所以我最初的想法是扩展 Locator 使其具有 ::getFooModel() 但现在看来我违反了开放/封闭原则，因为我每次都必须修改 Locator我介绍了一个新的模型类。

为了满足 OCP，我可以使用 Dynamic Service Locator(也在 Fowler 的页面上进行了描述)，但是出于与他相同的原因，我并不完全相信它，即它不够明确。

另一种解决方案是将所有模型的方法设为静态。所以:

fooItem1234 = FooModel::findById(1234);

我喜欢这个，因为它是零样板文件。我可以创建一个新的模型类，然后从任何地方开始用一行调用它。但是现在模型依赖于 Locator 来找到它的数据库连接，我不确定我对此有何看法。首先，如果我需要在单独的数据库连接上打开两个 fooModel，那将是一团糟和/或不可能。也就是说，我目前实际上不需要这样做，所以这个选项看起来有点诱人。

最后是 DI。但正如我上面所说，我认为这对于这个小项目来说可能太多了。

结论:我有点卡在这里，非常感谢 StackOverflow 专家的一些建议!

Answer 1

为什么您认为 DI 对您的项目来说太过分了？ Constructor Injection 等 DI 模式比 Service Locator(我认为是反模式)更简单、更清晰。

我认为 Service Locator 是一种反模式，因为它对 API 的用户来说是完全不透明的，哪些依赖项需要到位；因此，您可以在服务定位器会抛出异常的上下文中轻松地调用您的对象的方法，而 API 绝对不会给您任何关于这种情况的线索。

您不需要 DI 容器来使用 DI。如果只有一个简单的项目，您可以使用所谓的 Poor Man's DI，您可以在其中手动连接依赖项。