Questions tagged «ioc-containers»

我知道直接实例化类内部的依赖关系被认为是不好的做法。这是有道理的，因为这样做紧密地结合了所有内容，从而使测试变得非常困难。 我遇到的几乎所有框架似乎都倾向于使用容器进行依赖注入而不是使用服务定位器。通过允许程序员指定当类需要依赖时应返回哪个对象，两者似乎都实现了相同的目的。 两者有什么区别？为什么我要选择一个？

107 dependency-injection  ioc-containers  service-locator 

这些话invert或control根本不使用在我见过的定义来定义控制反转。 定义 维基百科 控制反转（IoC）是一种编程技术，在此以面向对象编程的形式表示，其中对象耦合在运行时由汇编程序对象绑定，通常在编译时使用静态分析是未知的。〜http://en.wikipedia.org/wiki/Inversion_of_control 马丁·福勒 控制反转是Java社区中的一种常见模式，可帮助连接轻量级容器或将来自不同项目的组件组装到一个内聚的应用程序中。〜基于 http://www.martinfowler.com/articles/injection.html （改写） 那么，为什么将控制反转称为控制反转？什么控制被颠倒了？有没有一种方法可以使用术语“ 反转和控制”来定义“控制反转”？

98 naming  definition  ioc-containers  inversion-of-control 

使用依赖注入和控制反转容器是否应该从代码中删除所有出现的“ new”关键字？ 换句话说，是否应该将每个对象/依赖项（无论多么简单或短暂）都“注册”到IoC容器中，并注入到需要使用它们的方法/类中？ 如果不是，您如何在new关键字IoC容器中注册依赖项/对象与通过关键字“内联”创建的具体引用之间划清界限？

21 .net  dependency-injection  ioc-containers 

尽管它很流行，但是是否有任何经验证据表明依赖注入（和/或使用DI容器）有助于例如减少错误计数，提高可维护性或提高现实软件项目的开发速度？

18 design-patterns  dependency-injection  inversion-of-control  ioc-containers  evidence-based 

我在许多项目中都为.Net使用了各种IoC容器（Castle.Windsor，Autofac，MEF等）。我发现它们往往经常被滥用，并鼓励许多不良行为。 是否有用于IoC容器的既定实践，特别是在提供平台/框架时？作为框架编写者，我的目标是使代码尽可能简单和易于使用。我宁愿写一行代码来构造一个对象，而不是十行甚至两行。 例如，我注意到了一些代码气味，并且对以下内容没有好的建议： 构造函数的大量参数（> 5）。创建服务往往很复杂；尽管所有组件很少是可选的（除了可能在测试中），所有依赖项都是通过构造函数注入的。 缺乏私人和内部阶级；这可能是使用C＃和Silverlight的特定限制，但是我对如何解决它感兴趣。如果所有的类都是公共的，很难说框架接口是什么。它使我可以访问我可能不应该接触的私人部件。 将对象生命周期耦合到IoC容器。手动构造创建对象所需的依赖项通常很困难。对象生命周期通常由IoC框架管理。我见过大多数班级都注册为Singletons的项目。您缺乏明确的控制，还被迫管理内部（与上述要点有关，所有类都是公共的，因此您必须注入它们）。 例如，.Net框架具有许多静态方法。例如DateTime.UtcNow。很多次，我都将这种包装和注入作为构造参数。 依赖于具体的实现使我的代码难以测试。注入依赖关系会使我的代码难以使用-特别是在类具有许多参数的情况下。 如何提供可测试的界面以及易于使用的界面？最佳做法是什么？

18 .net  silverlight  dependency-injection  ioc-containers  inversion-of-control 

我已经看到一些建议在代码中使用IoC容器的方法。动机很简单。采取以下依赖项注入代码： class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest( std::auto_ptr<Dependency> d = std::auto_ptr<Dependency>(new ConcreteDependency) ) : d_(d) { } }; TEST(UnitUnderTest, Example) { std::auto_ptr<Dependency> dep(new MockDependency); UnitUnderTest uut(dep); //Test here } 进入： class UnitUnderTest { std::auto_ptr<Dependency> d_; public: UnitUnderTest() { d_.reset(static_cast<Dependency *>(IocContainer::Get("Dependency"))); } }; TEST(UnitUnderTest, Example) { UnitUnderTest uut; //Test here …

17 dependency-injection  inversion-of-control  ioc-containers 

如果这似乎又是一个重复的问题，我深表歉意，但是每次我找到有关该主题的文章时，它大多只是在谈论DI是什么。因此，我得到了DI，但我试图了解每个人似乎都在使用的IoC容器的需求。IoC容器的目的真的只是为了“自动解决”依赖项的具体实现吗？也许我的类往往没有几个依赖关系，也许这就是为什么我认为没什么大不了的，但是我想确保我正确地理解了容器的效用。 我通常将我的业务逻辑分解为一个可能看起来像这样的类： public class SomeBusinessOperation { private readonly IDataRepository _repository; public SomeBusinessOperation(IDataRespository repository = null) { _repository = repository ?? new ConcreteRepository(); } public SomeType Run(SomeRequestType request) { // do work... var results = _repository.GetThings(request); return results; } } 因此，它仅具有一个依赖性，在某些情况下可能具有第二或第三依赖性，但并非经常如此。因此，任何调用此方法的都可以传递其自己的存储库，也可以允许其使用默认存储库。 就我对IoC容器的当前了解而言，该容器所做的只是解析IDataRepository。但是，如果这就是全部，那么我就没有看到太多的价值，因为当没有依赖项传入时，我的操作类已经定义了一个回退。所以我唯一想到的另一个好处是，如果我有多个操作，例如这个使用相同的后备仓库，我可以在注册表/工厂/容器的一个地方更改该仓库。那太好了，是吗？

15 c#  dependency-injection  inversion-of-control  ioc-containers 

像Google Guice这样的依赖注入框架为其使用（来源）提供了以下动机： 要构造一个对象，首先要建立它的依赖关系。但是要构建每个依赖项，您需要其依赖项，依此类推。因此，在构建对象时，确实需要构建对象图。 手工构建对象图是劳动密集型（...），并且使测试变得困难。 但是我不赞成这种观点：即使没有依赖注入框架，我也可以编写易于实例化且易于测试的类。例如，Guice动机页面中的示例可以用以下方式重写： class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = transactionLog; } // constructor for production, calling the (productive) constructors of the collaborators public BillingService() …

13 design-patterns  object-oriented  dependency-injection  ioc-containers 

已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗？更新问题，使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 我一直在思考如何将依赖项注入更好地直接集成到类似C＃的语言中。我想出一个潜在的解决方案，希望听听您的意见。我没有使用很多依赖注入框架，所以可能有些东西我忽略了 无论如何，该想法是能够使用关键字将属性声明为“可注入”。当实例化一个对象，并且未通过构造函数或对象初始化程序初始化该属性时，它将从某些全局服务中请求该属性类型的实例。 同样，您可以为该服务注册不同类型的处理程序，以便可以实例化注入的属性类型。 使用这种IMO架构的好处是它相当灵活且易于使用。不利之处在于，每次您启动带有注入的类时，对单身人士进行标注都可能会有一些开销。 再说一次，对于在高性能解决方案中经常实例化的类来说，这只是一个问题，所以这不是什么大问题。在这些情况下，也许您可​​以使用某种工厂。 思想，问题，问题，更好的主意？ 码 public class SomeClass { public SomeClass() { //implicit behavior if Animal is not set in constructor or initializer this.Animal = GlobalInjector.Get(this,typeof(Mammal)) } public injectable Mammal Animal { get; set; } } GlobalInjector.Register(typeof(Mammal), () => return new Mammal(someParameter));

10 programming-languages  dependency-injection  ioc-containers 

我试图弄清楚何时使用DIC / IoC注册表来配置我的软件以及何时使用工厂，以及这两种方法背后的原因。 我正在使用StructureMap作为我的DI容器（DIC），使用注册表很容易配置它。在DIC中，从某种意义上说，实际上所有注册的对象都是静态的，一旦配置了DIC并且在DIC中将它们配置为单例，就不需要在运行时更改/交换任何实现/实例。但是，由于我的软件（SW）将在不同的设备上运行，因此我确实需要根据运行我的SW的设备选择特定于设备的注册表，以便相应地配置硬件。 由于某些对象的构造需要读取配置文件，因此我正在使用工厂将这些实例返回给DIC，以便将配置的读取与对象的创建分开。我在DIC中为相应的插件类型注册了工厂吸气剂。 现在说我有一个插件类型IMotor与具体类型Motor1和Motor2，这应该由厂家来处理。现在，有两种方法可以决定如何配置设备： 我将有关运行SW的设备的信息传递给，MotorFactory并且它返回正确的电动机，Motor1或者Motor2。在这种情况下，决定的逻辑是在工厂内部。 我根据运行它，并创建两个工厂的设备配置DIC Motor1Factory和Motor2Factory，其中一个创建Motor1和其他 Motor2。在这种情况下，对于IMotor使用Motor1Factory或的设备特定的注册表，我会有不同的注册表项Motor2Factory。 现在我的问题是：这两种方法中哪一种更可取，为什么？在我看来，第一种情况并非一帆风顺，而且令人费解，因为我在整个代码库中扩展了决定实例化哪种类型的逻辑。在第二种情况下，由于我将需要（几乎）每种具体类型的工厂，因此我实际上在代码中增加了工厂的数量。当将抽象工厂添加到组合中时，这让我更加困惑。 再说一遍：什么时候应该使用一种方法？更重要的是：什么是决定走哪条路的好指标？

9 configuration  factory  ioc-containers