值对象是否是DI设计模式的有效依赖项？

Question

我看到的所有 DI 的例子中，它们依赖的对象都是其他类，比如服务。但实际上，一个对象可能会严重或者关键地依赖配置值，比如字符串和资源包装器（文件/路径/URI/URL），而不是整个大字符串/文档或者 reader。

需要注意的是，这里只讨论 DI 在 Java 或者 C# 语法中的设计模式，而不是任何特定的 DI 框架如何处理此问题。

例如，假设我有这样的一个类，它返回一个字符串（相对路径，基于某些晦涩的实现逻辑）。它（以及它的各种实现）对于“项目位置”具有配置/初始化依赖项，因为用户可能在他们的机器上有各种项目，并且每当调用此类时，它将根据给定的项目执行一些逻辑。

public abstract class PathResolver {

    protected File projectFilesLocation;

    public RoutinePathResolver(File projectFilesLocation) {
        this.projectFilesLocation = projectFilesLocation;
    }

    public abstract String getPath(String someValue);
}

我并不是只为了单元测试才使用DI（天哪，我甚至没有做单元测试，这个项目已经存在）我只是想要将我的依赖项/创建关注点和逻辑关注点分离。

- Zombies

Answer 1

只要您想注入的内容，比如文件位置，是该类直接使用的内容，则注入它是完全有效的。对于诸如File或String之类的Object，这与Service没有区别。它是您的类的依赖项，因此需要应用DI。

- James

---

但另一方面，可以注入一个ConfigurationSettings接口，它执行返回该字符串值的服务？也许是从存储库、配置文件或其他什么地方。这将会有所不同。 - Zombies

你可以这样做，但在我看来，ConfigurationSettings接口最终会变成一个上帝对象，导致所有的东西都依赖于它。最好直接将每个类所需的特定配置注入到其中。也许如果你想要不同的文件加载方式，可以使用一个FileProvider接口，例如有CMSFileProvider和LocalSystemFileProvider两种实现方式。 - James

这要看情况。如果一个具体的配置 VO（比如 PathResolvedConfig）只携带了特定类（或接口）的配置数据，那么这是完全可以的。但如果一个 ApplicationConfig VO 只使用了其中一部分数据，那就绝对不行。 - Creynders

很好的观点，Creynders。如果配置类具有足够高的内聚性，那么这不是问题，而且通常会使生活更轻松。我倾向于对此和参数对象模式使用相同的经验法则。如果您有超过3个值，则封装在VO中。 - James