使用依赖项注入容器时静态确定缺失的依赖项

发布于 2024-09-17 07:08:03 字数 343 浏览 7 评论 0原文

使用依赖项注入容器时，执行解析时会检测到缺少的依赖项。这是在运行时。

本文介绍了部分解决方案。验证您的行为（特别是如果您使用抽象工厂子解决方案进行运行时解析）：

它将有助于简化测试、调试和维护，但仍然需要执行测试来 ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx" rel="nofollow noreferrer">http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx

使用依赖项时注入容器，有没有办法静态确定所有依赖项都将得到解决？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

ま昔日黯然 2024-09-24 07:08:03

托管可扩展性框架 (MEF) 可以做到这一点。为了使分析准确，您需要遵守一些最佳实践，但结果在其他方面都很好。

要分析一组程序集，请使用命令行工具 - 请参阅 http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line .aspx。这可以从 Visual Studio 或持续集成服务器中的构建脚本运行 - http://blogs.msdn.com/b/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx 。

您可以使用 MefContrib 项目的 Visual MEFX 直观地完成此操作（再次通过一组程序集） - 请参阅 http://xamlcoder.com/blog/2010/04/10/updated-visual-mefx/

MEF 通过非常声明性（配置的标准属性）和使用来支持此功能一个惰性工作的底层组合模型（它可以在不创建任何实例的情况下构建图表......需要一些时间来理解。）

回复收藏 0 原文

情泪▽动烟 2024-09-24 07:08:03

简短的回答：不，这是不可能的。

这样做需要能够将所有组件及其依赖项（容器元数据）表示为图形，以便对其进行分析。问题是，容器越复杂，实现这一点就越困难。以温莎为例。它的众多扩展点使依赖关系过于动态而无法表示为图形。惰性组件加载器、处理程序选择器、工厂、组件模型贡献者、子解析器都参与该过程，并且它们可以是任意用户代码，这使得无法进行静态分析。

静态分析对于一个普通的容器来说可能是可行的，但是这个假设的容器对于现实世界的项目来说几乎毫无用处。

因此，像往常一样，这是一种权衡，我们能做的最好的事情就是进行一些测试，以测试容器中所有已注册组件的实际分辨率。 StructureMap 有一个 AssertConfigurationIsValid() 方法来做到这一点。

即便如此，可能还有更微妙的错误没有被捕获，例如

回复收藏 0 原文

蓝色星空 2024-09-24 07:08:03

除了 Mauricio 所说的之外，Windsor 2.5 还有一个功能，在诊断缺少依赖项的问题或仅查看容器中的组件时，您可能会发现该功能很有用。

我在博客中介绍了它的测试版这里。它现在更加有用，并且与 Windsor 中的所有内容一样 - 它是可扩展的，因此您可以在该列表中添加自己的项目。

替代文字

回复收藏 0 原文

梦里南柯 2024-09-24 07:08:03

也许不适用于依赖注入容器。但是，您可以手动执行依赖项注入，而无需容器。例如：

var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();

如果它可以编译，则所有依赖项都存在。

然而，一旦依赖关系图变得足够大，以至于你无法将其完全保留在你的脑海中（特别是混合了一些循环依赖关系），麻烦就会出现。如果您进行涉及重新排列依赖项的重构，那么调整构造函数调用的顺序将变得很困难。

Maybe not with a dependency injection container. However, you can do dependency injection manually, without a container. For example:

var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();

If it compiles then all the dependencies are there.

However, trouble looms as soon as the dependency graph grows large enough that you can't keep it entirely in your head (espcially with some circular dependencies thrown in the mix). If you do refactorings that involve rearranging of dependencies, then it will become hard work to adapt the order of constructor calls.

回复收藏 0 原文

~没有更多了~