Questions tagged «dependency-injection»

什么是之间的差异Service，Provider并Factory在AngularJS？

3319 angularjs  dependency-injection  angularjs-service  angularjs-factory  angularjs-provider 

已经发布了几个问题，其中包括有关依赖注入的特定问题，例如何时使用它以及使用什么框架。然而， 什么是依赖项注入？何时/为什么/不应该使用它？

3074 design-patterns  language-agnostic  dependency-injection  terminology 

我正在SpringSource上浏览一些博客，在其中一个博客中，作者正在使用@Inject，我想他也可以使用@Autowired。 这是一段代码： @Inject private CustomerOrderService customerOrderService; 我不知道之间的区别@Inject和@Autowired，如果有人解释他们的区别将不胜感激，什么情况下要使用哪一个？

694 java  spring  dependency-injection  autowired  inject 

已关闭。这个问题是基于观点的。它当前不接受答案。 6年前关闭。 已锁定。该问题及其答案被锁定，因为该问题是题外话，但具有历史意义。它目前不接受新的答案或互动。 我使用依赖注入（DI）已有一段时间了，注入了构造函数，属性或方法。我从来没有觉得需要使用控制反转（IoC）容器。但是，我阅读的内容越多，社区使用IoC容器的压力就越大。 我玩过.NET容器，如StructureMap，NInject，Unity和Funq。我仍然看不到IoC容器如何使我的代码受益/改进。 我也害怕在工作中开始使用容器，因为许多同事会看到他们不理解的代码。他们中的许多人可能不愿意学习新技术。 请说服我，我需要使用IoC容器。与工作中的其他开发人员交谈时，我将使用这些参数。

598 dependency-injection  inversion-of-control  ioc-container 

我试图了解依赖项注入（DI），但再次失败了。看起来真傻。我的代码永远不会混乱。我几乎不编写虚拟函数和接口（尽管我在一个蓝色的月亮中只做过一次），并且我所有的配置都使用json.net（有时使用XML序列化器）神奇地序列化为一个类。 我不太了解它能解决什么问题。看起来好像是这样说的：“嗨。当您运行此函数时，返回此类型的对象并使用这些参数/数据。” 但是...我为什么要使用它？请注意，我也从来不需要使用object它，但是我知道这是为了什么。 在构建使用DI的网站或桌面应用程序时，有哪些实际情况？对于某些人为什么要在游戏中使用接口/虚拟功能，我可以很容易地提出一些案例，但是在非游戏代码中使用它非常少见（很少见，我什至不记得一个实例）。

536 dependency-injection 

根据马丁·福勒（Martin Fowler）的论文，控制反转是程序控制流反向的原理：外部源（框架，服务，其他组件）代替程序控制程序流，而由程序控制流它。就像我们将某些东西插入其他东西一样。他提到了有关EJB 2.0的示例： 例如，会话Bean接口定义了ejbRemove，ejbPassivate（存储到辅助存储）和ejbActivate（从被动状态恢复）。您不必控制何时调用这些方法，而可以控制它们的作用。容器给我们打电话，我们不给它打电话。 这导致框架和库之间的差异： 控制反转是使框架与库不同的关键部分。库本质上是您可以调用的一组函数，这些天通常组织成类。每个调用都会执行一些工作，并将控制权返回给客户端。 我认为，DI是IOC的观点意味着对象的依赖关系被颠倒了：与其控制自己的依赖关系，不如生命周期……还有其他事情为您服务。但是，正如您手动告诉我的那样，DI不一定是IOC。我们仍然可以拥有DI而没有IOC。 但是，在本文中（来自pococapsule，这是另一个C / C ++的IOC框架），它表明，由于IOC和DI，IOC容器和DI框架要优于J2EE，因为J2EE将框架代码混合到了组件中，因此不会使其成为普通的Java / C ++对象（PO​​JO / POCO）。 除依赖注入模式以外的控制容器的反转（归档链接） 进一步阅读以了解旧的基于组件的开发框架有什么问题，这导致了上面的第二篇论文：控制反转的原因和内容（归档链接） 我的问题：什么是IOC和DI？我很困惑。基于pococapsule，IOC不仅仅是对象或程序员与框架之间的控制反转。

525 dependency-injection  inversion-of-control 

引用依赖注入的大多数示例，我们也可以使用工厂模式来解决。看起来在使用/设计时，依赖项注入和工厂之间的差异变得模糊或稀薄。 曾经有人告诉我，您如何使用它与众不同！ 我曾经使用StructureMap一个DI容器来解决问题，后来我对其进行了重新设计以使其与简单的工厂一起工作，并删除了对StructureMap的引用。 谁能告诉我它们之间的区别以及在哪里使用什么，这里的最佳做法是什么？

496 dependency-injection  factory-pattern  design-patterns 

我阅读了许多文章，这些文章解释了如何设置实体框架，DbContext以便使用各种DI框架为每个HTTP Web请求创建和使用一个实体框架。 为什么这首先是个好主意？通过使用这种方法，您可以获得什么优势？在某些情况下这是个好主意吗？使用DbContext每个存储库方法调用实例化s 时，您是否可以使用该技术做一些事情？

398 c#  asp.net  entity-framework  dependency-injection  dbcontext 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 7年前关闭。 哪些C＃/。NET依赖注入框架值得研究？您能说出它们的复杂性和速度。

386 c#  .net  dependency-injection  inversion-of-control 

我应该在DI中使用哪个注释@Resource（jsr250）或@Autowired（特定于Spring）？ 我已经成功地在过去使用两种，@Resource(name="blah")和@Autowired @Qualifier("blah") 我的直觉是坚持使用该@Resource标签，因为它已被jsr人士批准。 有人对此有强烈的想法吗？

380 java  spring  dependency-injection  annotations  autowired 

按照目前的情况，这个问题不适合我们的问答形式。我们希望答案得到事实，参考或专业知识的支持，但是这个问题可能会引起辩论，争论，民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出，请访问帮助中心以获取指导。 8年前关闭。 我正在尝试在这里将DI作为一种模式进行介绍，我们的一位主要开发人员想知道：使用依赖注入模式的缺点 -如果有的话-有什么缺点？ 请注意，我正在这里寻找（如果可能）详尽列表，而不是对该主题进行主观讨论。 澄清：我正在谈论的是依赖注入模式（请参阅Martin Fowler的本文），而不是特定的框架，无论是基于XML的（例如Spring）还是基于代码的（例如Guice），还是“自卷式” 。 编辑：在这里/ r / programming进行了一些很棒的进一步讨论/讨论/辩论。

336 design-patterns  dependency-injection 

在Java中，IoC / DI是一种非常普遍的做法，广泛用于Web应用程序，几乎所有可用的框架和Java EE中。另一方面，也有很多大型的Python Web应用程序，但是除了Zope（我听说过应该非常可怕的编码）之外，IoC在Python世界中似乎并不普遍。（如果您认为我错了，请举一些例子）。 当然，有一些流行的Java IoC框架的克隆可用于Python，例如springpython。但是它们似乎都没有被实际使用。至少，我从来没有在一个stumpled Django的或SQLAlchemy的 + <insert your favorite wsgi toolkit here>，它使用类似的东西，基于Web应用程序。 我认为IoC具有合理的优势，例如可以轻松替换django-default-user-model，但是在Python中广泛使用接口类和IoC看起来有些奇怪，而不是“ pythonic”。但是也许有人有一个更好的解释，为什么IoC在Python中没有得到广泛使用。

312 python  design-patterns  dependency-injection  inversion-of-control  architecture 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 3年前关闭。 改善这个问题 冒着进入神圣战争领土的风险，这些流行的DI / IoC框架的优点和缺点是什么，可以轻易地认为是最好的吗？..： Ninject 统一 温莎城堡 Autofac 结构图 我这里没有列出其他的C＃DI / IoC框架吗？ 就我的用例而言，我正在构建客户端WPF应用程序和WCF / SQL服务基础结构，易用性（尤其是在语法简洁明了方面），一致的文档，良好的社区支持和性能都是重要因素。由我选择。 更新： 引用的资源和重复的问题似乎已经过时了，知道所有这些框架的人能挺身而出并提供一些真正的见解吗？ 我意识到，关于该主题的大多数意见可能会带有偏见，但我希望有人花时间研究所有这些框架，并且至少要有一个客观的比较。 如果以前没有做过，我很愿意进行自己的调查，但是我认为这至少是一些人已经做过的。 第二次更新： 如果您确实有多个DI / IoC容器的使用经验，请对这些容器的优缺点进行排名和总结，谢谢。这不是发现人们制作的所有晦涩的小容器的一种练习，我正在寻找流行的（和活动的）框架之间的比较。

308 c#  dependency-injection  unity-container  ioc-container  ninject 

两种模式似乎都是控制反转原理的一种实现。也就是说，对象不应该知道如何构造其依赖项。 依赖注入（DI）似乎使用构造函数或setter来“注入”它的依赖项。 使用构造函数注入的示例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo(IBar bar) { this.bar = bar; } //... } Service Locator似乎使用了一个“容器”，它连接了它的依赖项并给foo它的标志。 使用服务定位器的示例： //Foo Needs an IBar public class Foo { private IBar bar; public Foo() { this.bar = Container.Get<IBar>(); } //... } 因为我们的依赖关系只是对象本身，所以这些依赖关系具有依赖关系，后者甚至具有更多的依赖关系，依此类推。因此，控制容器（或DI容器）的反转诞生了。示例：温莎城堡，Ninject，结构图，弹簧等） 但是，IOC / …

303 design-patterns  dependency-injection  service-locator 

如何使用ASP.NET Core MVC内置的依赖项注入框架手动解析类型？ 设置容器非常简单： public void ConfigureServices(IServiceCollection services) { // ... services.AddTransient<ISomeService, SomeConcreteService>(); } 但是，ISomeService不进行注射怎么办？例如，我要这样做： ISomeService service = services.Resolve<ISomeService>(); 中没有此类方法IServiceCollection。

302 c#  dependency-injection  asp.net-core  asp.net-core-mvc