最具争议性的帖子，IoC，Ninject，只是让东西发挥作用
我从哪里开始？
在学习编程的过程中，人们会遇到设计模式、架构选择等问题。对我来说，我从概念上理解 DI、IoC 以及为什么需要它们/它们是好的。模块化、低耦合高内聚——我明白了。
例如，我正在借助 MVP 模式构建一个小型测试网站，其中演示者没有具体的视图，而是使用视图实现的接口。它还引用了服务层（位于演示者和 BLL 之间），同样，没有具体的内容，使用一个接口。都是好东西。
（手动）IoC 正在将具体对象的实例化向上推，直到对象需要被注入到某个地方。换句话说，依赖性仍然存在，只是更高了。输入 IoC 容器。并输入挫败感。
我知道它们在那里，我知道它们的用途。我选择使用ninject。凉爽的。所以，我开始寻找。在我的下载中，我有一堆文件：
- LICENSE.TXT
- Ninject.dll
- Ninject.pdb
- Ninject.xml
另一个文件夹，名为扩展
- CommonServiceLocator.NinjectAdapter.dll
- CommonServiceLocator.NinjectAdapter.pdb
好吧...一堆文件。使用哪个？我不知道。我把它们放在哪里？我需要全部吗？问题问题...
也许阅读一些手册。 Ninject 维基@github。正确的。我开始阅读 - 为什么使用 Ninject？手动依赖注入、Ninject 依赖注入 - 关于剑和匕首等的很好的例子。但我没有在任何地方读过如何实际操作/使用它。我应该把它放在 Visual Studio 中的什么位置？怎么称呼呢？如何？
另外，它还向我提供了这段代码：
Bind<IWeapon>().To<Sword>();
它说每次调用 IWeapon 时，都会给出 Sword 的实现。呃...好吧，还有一把匕首 - 也许我不想每次在构造函数中使用例如 IWeapon 作为参数时都得到一把剑，但如何做到这一点？没说啊！每次使用 IWeapon 时我都会被剑卡住吗？如果不是，那么改变它的代码是什么？又如何呢？
它说，当你有一堆构造函数时，它只会采用参数最多的那个。好的。对于参数比参数最多的构造函数少一点的构造函数有什么作用？我不能将 ninject 与这些构造函数一起使用吗？或者...它是如何工作的？再说一遍——它没有说任何地方。诅咒！
在 wiki 中，有一个指向 SO 上最具争议的帖子的链接。这是关于一个名叫乔尔的人如何谈论国际奥委会的一些事情，从而引发了激烈的战争/书呆子气。但你知道吗？我敢说我有点支持这个家伙。为什么？也许 IoC 的概念很简单，但天哪 - 最终知道如何使用它，在某些情况下该怎么做等等，真的真的令人沮丧。搜索谷歌大多要么没有什么有用的东西，要么确实有很多值得阅读的东西，中间有一些令人费解的东西。我发现这个人在某种意义上可能是对的——因为理解概念并向那些不理解你认为简单的事情的人解释真的很难。
为什么它不能更像“下载文件 - 取出该文件并将其放在方便的地方，然后转到 Visual Studio，制作一个新地图并引用 dll。要使用它，请执行以下步骤”，然后解释每个步骤并给出了非常详细的原因。没有代码片段。这令人沮丧。
所以，有人可能想知道我的问题是什么。嗯，我想使用 Ninject。我需要什么？我该把它放在哪里？我怎样才能让它发挥作用？我是否必须在拥有 IWeapon 的地方都被一把剑卡住？当外面阳光明媚时，我在做什么？
Where do I start?
Over the course of learning to program one runs into design patterns, architectural choices etc. For me, I understand conceptually DI, IoC and why they are needed/good. Modularity, low coupling high cohesion - I get it.
For example, I am building a small test website with the help of the MVP pattern, where the presenter doesn't have a concrete View, but uses an interface that the View implements. It also has a reference to a service layer (which sits between the presenter and the BLL), again, nothing concrete, using an interface for that. All good stuff.
The (manual) IoC is making the instantiating of concrete objects pushed upwards, to the point that objects need to be injected somewhere, someplace. In other words, the dependency is still there, it is just higher up. Enter IoC containers. And enter frustration.
I know they are there, I know what they are used for. I opted to use ninject. Cool. So, I start looking. In my download I have bunch of files:
- LICENSE.TXT
- Ninject.dll
- Ninject.pdb
- Ninject.xml
another folder, called extensions
- CommonServiceLocator.NinjectAdapter.dll
- CommonServiceLocator.NinjectAdapter.pdb
Okay... a bunch of files. Which to use? I do not know. Where do I place them? Do I need all of them? Questions questions...
Maybe read some manual. Ninject wiki @ github. Right. I start reading - why use Ninject? Dependency Injection By Hand, Dependency Injection With Ninject - nice examples about swords and daggers and such. But I don't read anywhere how to actually do/use it. Where do I place it in Visual Studio? How to call it? How?
Also, it presents me with this code:
Bind<IWeapon>().To<Sword>();
It says that everytime IWeapon is called, an implementation of sword is given. Eh... okay, there was a dagger as well - maybe I don't want to get a sword everytime I have e.g. IWeapon as parameter in my constructor, but how to do that? It doesn't say! Am I stuck with a sword everytime I use IWeapon? If not, what is the code to change that then? And how?
It says that when you have a bunch of constructors, it will only take the one with the most parameters. Okay. What does it do with the constructors that have a little less parameter than the constructor with the most? Can't I use ninject with these constructors? Or... how does it work? Again - it doesn't say anywhere. Curses!
In the wiki, there's a link to the Most Controversial Post on SO. It is about a guy named Joel how says some things about IoC that enabled the flame war/nerdrage. But you know what? I dare to say that I kinda root for this guy. Why? Maybe the concept of IoC is simple, but by god - getting to the point of finally knowing how to use it, what to do in case of certain situations etc. is really really frustrating. Searching google mostly turns up either nothing useful, or indeed a lot to read with convoluted stuff inbetween. I find that the guy might be right in some sense - in that it is really hard to understand concepts and explain to someone who doesn't understand the things you find simple.
Why can't it be more like "Download the files - get this file out and place it somewhere handy, then go to Visual Studio, make a new map and reference the dll. To use it do these steps" and then explaining every step with a very good and detailed why. No snippets of code. It is frustrating.
So, one might wonder what my question is. Well, I want use Ninject. What do I need? where do I place it? How do I get it to work? Do I have to be stuck with a sword everywhere I have IWeapon? What am I doing at work when the sun is shining outside?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我有一组非常简单的 ninject 示例代码，当我们将它引入我们的项目时，我为一些开发人员制作了这些代码。它现在只涵盖基本的绑定等。与它如何与 MVC 或更高级的主题（如上下文绑定）配合使用并不重要。这一切都是作为 nUnit 测试完成的，所以我希望它很容易理解。它没有展示如何将其正确地应用到您的项目中。我希望很快能做一个真正的MVC示例项目。
https://github.com/ryber/Ninject-Examples
希望有所帮助。
I have a very simple set of example code for ninject that I made for some of our developers when we introduced it to our project. It just covers basic bindings and such right now. Not so much with how it works with MVC or more advanced topics like contextual bindings. It's all done as nUnit tests so I hope it's easy to follow. What it does NOT show is how to properly work it into your project. I hope to soon do a true example MVC project.
https://github.com/ryber/Ninject-Examples
Hope that helps.
对于 Web 项目，我建议使用 MVC3。请参阅 https://github.com/ninject/ninject.web.mvc/wiki/ MVC3 关于让它与 Ninject 一起工作。
For web projects I recommend using MVC3. See https://github.com/ninject/ninject.web.mvc/wiki/MVC3 about getting it to work with Ninject.