我正在阅读Injection by Hand 和Ninjection（以及Why use Ninject）。我遇到了两个困惑：
我已经熟悉的手动注射技术，但我不熟悉 Ninjection，因此不确定完整的程序如何工作。也许提供一个完整的程序会有所帮助，而不是像在该页面上所做的那样，将程序分解为多个片段
我仍然不明白这如何使事情变得更容易。我想我错过了一些重要的东西。如果您正在创建一组注入然后在两个大组之间同时切换，我可以看到注入框架将如何有所帮助（这对于模拟等很有用），但我认为还有更多比起那个来说。但我不确定是什么。或者也许我只是需要更多的例子来说明为什么这是令人兴奋的。
【问题讨论】：
标签： dependency-injection ninject c#
在没有 DI 框架的情况下注入依赖项时，最终会在整个应用程序中出现箭头代码，告诉类如何构建它们的依赖项。
public Contact()
: this(new DataGateWay())
{
}
但是如果你使用像 Ninject 这样的东西，所有的箭头代码都在一个地方，这样可以更容易地更改所有使用它的类的依赖关系。
internal class ProductionModule : StandardModule
{
public override void Load()
{
Bind<IDataGateway>().To<DataGateWay>();
}
}
【讨论】：
我仍然不明白这如何使事情变得更容易。我想我错过了一些重要的东西。
如果我们只需要开发分立的组件，每个组件都提供我们可以轻松理解、重用和维护的独特功能，那不是很好吗？我们只在组件上工作。
阻止我们这样做的原因是，我们需要一些能够以某种方式将这些组件自动组合并管理到工作应用程序中的基础设施。我们可以使用执行此操作的基础架构 - IOC 框架。
因此，IOC 框架不是关于管理依赖关系或测试或配置。相反，它关于管理复杂性，使您能够只工作和思考组件。
【讨论】：
它允许您通过模拟特定代码块所需的接口来轻松测试代码。它还允许您轻松地交换功能而不会破坏代码的其他部分。
这都是关于内聚和耦合的。
您可能不会看到小型项目的好处，但是一旦您超越了小型项目，当您必须对系统进行更改时就会变得非常明显。用过 DI 就轻而易举了。
【讨论】：
我真的很喜欢某些框架的自动装配方面......当你不必关心你的类型需要被实例化时。
编辑： 我读了this article by Ayende @ Rahien。我真的支持他的观点。
【讨论】：
使用大多数框架的依赖注入可以在运行时配置，无需重新编译。
【讨论】：
如果你的代码达到了代码中几乎没有依赖项的程度，依赖注入会变得非常有趣。一些依赖注入框架允许你在配置文件中定义你的依赖。如果您需要一个非常灵活的软件，并且需要在不修改代码的情况下进行更改，这将非常有用。例如，工作流软件是此类解决方案的主要候选者。
【讨论】：
依赖注入对于Component Driven Development 是必不可少的。后者允许以更有效和更可靠的方式构建真正复杂的应用程序。
此外，它允许将常见的横切关注点从其他代码中清晰地分离出来（这导致代码库的可重用性和灵活性更高）。
相关链接：
【讨论】：