architecture - 最具争议的帖子，IoC，Ninject，只是让东西工作

Question

我从哪里开始？

在学习编程的过程中，会遇到设计模式、架构选择等。对我来说，我从概念上理解 DI、IoC 以及为什么需要/好的原因。模块化、低耦合、高内聚——我明白了。

例如，我正在借助 MVP 模式构建一个小型测试网站，其中演示者没有具体的 View ，而是使用 View 实现的接口(interface)。它还引用了一个服务层(位于演示者和 BLL 之间)，同样，没有什么具体的，为此使用了一个接口(interface)。都是好东西。

(手动)IoC 正在将具体对象的实例化向上推，以至于需要将对象注入(inject)某个地方，某个地方。换句话说，依赖性仍然存在，只是更高了。输入 IoC 容器。并进入沮丧。

我知道它们在那里，我知道它们的用途。我选择使用ninject。凉爽的。所以，我开始寻找。在我的下载中，我有一堆文件:

许可证.TXT

Ninject.dll

忍者.pdb

Ninject.xml

另一个文件夹，称为扩展

CommonServiceLocator.NinjectAdapter.dll

CommonServiceLocator.NinjectAdapter.pdb

好吧...一堆文件。使用哪个？我不知道。我应该把它们放在哪里？我需要所有这些吗？问题问题...

也许阅读一些手册。 Ninject 维基@github。对。我开始阅读 - 为什么使用 Ninject？手动依赖注入(inject)，使用 Ninject 进行依赖注入(inject) - 关于剑和 Dagger 等的好例子。但我没有在任何地方阅读如何实际使用它。我应该把它放在 Visual Studio 的什么位置？怎么称呼它？如何？

此外，它向我展示了以下代码:

Bind<IWeapon>().To<Sword>();

它说每次调用 IWeapon 时，都会给出一个剑的实现。嗯...好吧，还有一把 Dagger ——也许我不想每次都有剑，例如IWeapon 作为我的构造函数中的参数，但如何做到这一点？没说!我每次使用 IWeapon 时都会被剑卡住吗？如果不是，那么改变它的代码是什么？如何？

它说当你有一堆构造函数时，它只会采用参数最多的一个。好的。参数比最多的构造函数少一点的构造函数有什么作用？我不能在这些构造函数中使用 ninject 吗？或者......它是如何工作的？再次 - 它没有说任何地方。诅咒!

在 wiki 中，有一个指向 SO 上最具争议的帖子的链接。这是关于一个名叫 Joel 的人如何讲述有关 IoC 的一些事情，这些事情促成了火焰 war / Nerd 。但你知道吗？我敢说我有点支持这个家伙。为什么？也许 IoC 的概念很简单，但天哪——最终知道如何使用它，在某些情况下该怎么做等等真的很令人沮丧。搜索谷歌通常会发现没有任何用处，或者确实有很多东西需要阅读，中间夹杂着令人费解的东西。我发现这家伙在某种意义上可能是对的——因为很难理解概念并向不理解你认为简单的事情的人解释。

为什么不能更像“下载文件 - 把这个文件拿出来放在方便的地方，然后去 Visual Studio，制作一张新 map 并引用 dll。要使用它，请执行这些步骤”，然后解释每一步有一个非常好的和详细的原因。没有代码片段。这令人沮丧。

所以，有人可能想知道我的问题是什么。好吧，我想使用 Ninject。我需要什么？我应该把它放在哪里？我如何让它工作？我是否必须在拥有 IWeapon 的任何地方都被剑卡住？外面阳光明媚的时候我在做什么？

Answer 1

当我们将它引入我们的项目时，我为我们的一些开发人员制作了一组非常简单的 ninject 示例代码。它现在仅涵盖基本绑定(bind)等。与它如何与 MVC 或更高级的主题(如上下文绑定(bind))一起工作并没有那么重要。这一切都是作为 nUnit 测试完成的，所以我希望它很容易理解。它没有显示的是如何将它正确地应用到您的项目中。我希望尽快做一个真正的示例 MVC 项目。

https://github.com/ryber/Ninject-Examples

希望有帮助。