Questions tagged «inversion-of-control»

在过去的一年中，我使用依赖注入和IOC容器创建了一个新系统。这教会了我很多关于DI的知识！ 但是，即使在学习了概念和正确的模式之后，我仍然认为将代码解耦并将IOC容器引入旧版应用程序是一个挑战。该应用程序足够大，以至于真正的实现将是压倒性的。即使理解了价值并准予了时间。谁有时间抽出这样的东西？ 当然，目标是将单元测试引入业务逻辑！ 与防止测试的数据库调用交织在一起的业务逻辑。 我已经阅读了这些文章，并且了解了这篇Los Techies文章中描述的穷人依赖注入的危险。我了解它并没有真正分离任何东西。 我知道它可能涉及很多系统范围的重构，因为实现需要新的依赖项。我不会考虑在任何大小的新项目中使用它。 问题：可以使用穷人的DI 将可测试性引入旧版应用程序并开始滚动吗？ 另外，使用穷人的DI作为真正依赖注入的基层方法是否是教育该原理的需求和收益的有价值的方法？ 您是否可以重构具有数据库调用依赖关系的方法，并将该调用抽象到接口后面？简单地拥有这种抽象将使该方法可测试，因为可以通过构造函数重载传递模拟实现。 将来，一旦获得支持者的支持，就可以对该项目进行更新以实现IOC容器，并且构造函数将在那里使用抽象。

14 architecture  dependency-injection  legacy  inversion-of-control 

我是依赖注入的新手，我对应在应用程序中使用哪种样式有一些疑问。我刚刚阅读了Martin Fowler 的《控制容器的反转》和《依赖注入》模式，但是我无法获得构造函数，setter和接口注入之间的实际区别。 在我看来，一个使用另一个的原因仅是代码清理和/或清晰的问题。有什么区别？相对于其他方法，使用它们有什么优点或缺点，还是我刚才所说的？ 在我看来，构造函数注入是最直观的，而接口注入则是最少的。另一方面，setter注入是一个中间术语，但是，您是否应该能够更改最初注入的依赖对象的实例？这种注入方式是否可以确保需要依赖项的对象始终被注入？我相信不会，但是如果我错了，请纠正我。

12 design-patterns  dependency-injection  inversion-of-control 

是否有人在编译时启动了一个要进行IOC的项目（可能使用Roslyn或Linq MethodInfo发出）？ 到目前为止，我在IOC容器方面的经验非常好，排除了一些小问题 许多IOC容器启动缓慢，因为许多解析逻辑都在这里发生 通常很难确保可以解决，因为编译不再确保可以调用构造函数。 通常，IOC容器会增加运行时的开销（有些甚至不小，通常那些启动很快的容器运行缓慢） 在我看来，理想的解决方案是在构建链上添加一个编译步骤，该步骤添加一个Factory类而不是IOC。 有人做过吗？如果没有，为什么不呢？

11 c#  meta-programming  inversion-of-control 

在网络上的许多文章中，术语“控制反转”和“依赖反转原则”似乎混为一谈并用作同义词（进一步的混乱由称为“ DI-Containers”和“ IoC-Containers”的工具所强加）。Wikipedia的一篇文章很好地解释了IoC与DI不同： 控制反转（IoC）描述了一种设计，其中计算机程序的自定义编写部分从通用的可重用库接收控制流 因此，DIP是关于让模块依赖于抽象而不是具体的实现。 而IoC则是将程序流的控制权交给一个单独的模块。您可以让此模块执行的操作之一是在运行时解析依赖关系。 这种差异看起来确实很公平，但是我从未见过有人提到过IoC原理的任何其他应用程序，除了依赖关系解析之外。Wikipedia的定义非常广泛，似乎您可以使用一个模块进行更多的工作，该模块可以根据其配置和一些内部逻辑调用自定义代码。 因此，这里有一些我还无法弄清楚的问题： IoC和DIP之间的实际关系是什么？IoC始终是实现DIP的手段吗？ 为什么将依赖关系解决工具称为DI容器和IoC容器？这意味着DI和IoC是同一件事。 注意：这个问题不是DI和IoC有什么区别的重复，因为后者询问的是依赖注入，而不是依赖反转。

11 design-patterns  inversion-of-control  dependency-inversion