【发布时间】：2011-07-24 09:05:31
【问题描述】：
我从哪里开始？
在学习编程的过程中，会遇到设计模式、架构选择等。对我来说，我从概念上理解 DI、IoC 以及为什么需要/好的原因。模块化、低耦合、高内聚——我明白了。
例如，我正在借助 MVP 模式构建一个小型测试网站，其中演示者没有具体的视图，而是使用视图实现的接口。它还引用了一个服务层（位于演示者和 BLL 之间），同样，没有什么具体的，为此使用了一个接口。都是好东西。
（手动）IoC 正在将具体对象的实例化向上推，以至于对象需要在某个地方注入某个地方。换句话说，依赖性仍然存在，只是更高了。输入 IoC 容器。并输入挫败感。
我知道它们在那里，我知道它们的用途。我选择使用ninject。凉爽的。所以，我开始寻找。在我的下载中，我有一堆文件：
- 许可证.TXT
- Ninject.dll
- Ninject.pdb
- Ninject.xml
另一个文件夹，称为扩展
- CommonServiceLocator.NinjectAdapter.dll
- CommonServiceLocator.NinjectAdapter.pdb
好的……一堆文件。使用哪个？我不知道。我应该把它们放在哪里？我需要所有这些吗？问题问题...
也许阅读一些手册。 Ninject 维基@github。正确的。我开始阅读 - 为什么使用 Ninject？手动依赖注入，使用 Ninject 进行依赖注入 - 关于剑和匕首等的好例子。但我没有在任何地方阅读过如何实际使用/使用它。我应该把它放在 Visual Studio 的什么位置？怎么称呼它？怎么样？
此外，它还向我展示了以下代码：
Bind<IWeapon>().To<Sword>();
它说每次调用 IWeapon 时，都会给出一个剑的实现。嗯...好吧，还有一把匕首——也许我不想每次都有剑，例如IWeapon 作为我的构造函数中的参数，但如何做到这一点？没说！我每次使用 IWeapon 时都会被剑卡住吗？如果不是，那么改变它的代码是什么？怎么做？
它说当你有一堆构造函数时，它只会使用参数最多的那个。好的。参数比最多的构造函数少一点的构造函数有什么作用？我不能在这些构造函数中使用 ninject 吗？或者......它是如何工作的？再次 - 它没有说任何地方。诅咒！
在 wiki 中，有一个指向 SO 上最具争议的帖子的链接。这是关于一个名叫 Joel 的人如何讲述有关 IoC 的一些事情，这些事情促成了火焰战争/书呆子。但你知道吗？我敢说我有点支持这个家伙。为什么？也许 IoC 的概念很简单，但老天爷 - 最终知道如何使用它、在某些情况下该怎么做等等，真的真的令人沮丧。搜索谷歌通常会发现没有任何用处，或者确实有很多东西需要阅读，中间夹杂着令人费解的东西。我发现这家伙在某种意义上可能是对的 - 因为很难理解概念并向不理解您认为简单的事情的人解释。
为什么不能更像“下载文件 - 把这个文件拿出来放在方便的地方，然后转到 Visual Studio，制作一个新地图并引用 dll。要使用它，请执行这些步骤”，然后用非常好的和详细的原因解释每一步。没有sn-ps的代码。这很令人沮丧。
所以，有人可能想知道我的问题是什么。好吧，我想使用 Ninject。我需要什么？我应该把它放在哪里？我如何让它工作？我是否必须在拥有 IWeapon 的任何地方都被剑卡住？外面阳光明媚的时候我在工作什么？
【问题讨论】：
-
欢迎来到开源软件的世界 ;-)
-
@Mark Seemann - 我明白你在那里做了什么 ;-) 在我写作的时候，我正在阅读你的书的第一章。到目前为止一切顺利。
-
显然我不同意乔尔的观点，但我认为他提出了不容易被忽视的好观点。这都是关于代码质量是否相关的更大讨论的一部分——只要问 Bob 叔叔 :)
-
发布您的所有问题，我们会尽力解答
-
@Ruben Bartelink - 说真的，它是......好吧，当你知道（或有点知道）导致使用 DI 的东西/IoC 容器工作，然后当你想使用它时，你完全迷失了。你读了又读，你会得到一些知识——但大局仍然有点神秘。你知道，真正开始的拼图的其他部分。因为，真的有那么难吗？别人知道我不知道的事情吗？这是实验的问题吗？
标签： architecture dependency-injection ninject ioc-container