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

对于我所见过的所有DI示例，我始终将依赖关系视为其他类（如服务）。但是一个对象实际上可能依赖于配置值，比如字符串和资源包装器（File/Path/URI/URL，而不是整个大值字符串/文档或读者）。DI设计模式的值对象是否有效依赖关系？

请注意，这仅仅是关于Java或C＃语法中的DI设计模式，并非任何特定的DI框架如何处理此问题。

例如，假设我有这个类，它返回一个String（相对路径，基于一些模糊的实现逻辑）。它（而不是其各种实现者）对“projectLocation”具有配置/初始化依赖关系，因为用户可以在他们的机器上拥有各种项目，并且该类在调用时会根据给定的项目执行一些逻辑。

public abstract class PathResolver { 

    protected File projectFilesLocation; 

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

    public abstract String getPath(String someValue); 
}

我不使用DI只是单元测试（喘气我甚至没有单元测试，现有的项目）。我只是想分开我的依赖/创造性关注和逻辑关注时期。

来源

2013-03-21 Zombies

对于像我这样一见钟情的人，DI代表依赖注入（英文不是我的自然语言）:) – LaGrandMere 2013-03-21 11:43:53

假如你想注入的东西，例如文件位置，是类可以直接使用的东西，那么注入它是完全有效的。

在Object的情况下，如File或String那么这与称为Service的东西没有什么不同。这是你的课程的一个相关性因此DI适用。

来源

2013-03-21 12:14:33 James

但是另一方面，可以注入一个ConfigurationSettings接口，它执行返回所述String值的服务？也许从回购，配置文件或其他东西。会有区别。 – Zombies 2013-03-21 12:48:54

你可以做到这一点，但恕我直言，一个ConfigurationSettings接口最终成为上帝对象，你最终取决于它的一切。最好将每个类所需的特定配置直接注入到它中。也许如果你想要不同的文件加载方式，例如你可以用'FileFileProvider'和'LocalSystemFileProvider'实现'FileProvider'接口。 – James 2013-03-21 12:52:34

这取决于。有一个具体的配置VO是完全正确的。例如'PathResolvedConfig'。当且仅当它专门为该特定类（或接口，显然）携带配置数据时。仅使用其中一部分数据的'ApplicationConfig' VO绝对是一个禁忌。 – Creynders 2013-03-21 13:45:56

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

回答

相关问题