我应该在哪里使用 Ninject 2+ 进行注入(以及如何安排我的模块?) [英] Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)
问题描述
我有一个解决方案，其中包含两个相关的(与此问题相关的)项目，以及其他一些项目；
I have a solution with two relevant (to this question) projects, and a few others;
- 具有其他几个项目使用的功能的类库.
- ASP.NET MVC 应用程序.
我的问题基本上是我应该在哪里使用 Ninject 2 进行 IoC，考虑......
My question is basically where I should do IoC with Ninject 2, considering...
- 类库需要一些 DI 爱，其中包括需要 Web 请求特定会话对象的存储库类(想想工作单元).
- MVC 应用程序需要 DI，因为在 Ninject 2 中，您基本上是从 NinjectHttpApplication 继承的.
- 类库的单元测试需要意识到这一点以注入不同的存储库集.
- 出于同样的原因，需要注入 Web 应用的单元测试.
我在这里把自己画到了一个心理角落，因为我一开始只看到了三个选项.类库中的 DI，网络应用中的 DI，或者两者都有，但每个都有问题:
I have painted myself into a mental corner here, because I only saw three options to begin with. DI in the class library, DI in the web app, or both, but there are problems with each:
- 我不能在类库中只做 DI，因为 MVC 应用程序需要从 NinjectHttpApplication 开始继承.
- 我不能只在 MVC 应用程序中执行 DI - 毕竟其他库使用类库，无论如何，MVC 应用程序不应该对库的内部了解太多.
- 我想这是我能看到的唯一出路:两个项目的独立 IoC.类库和 MVC 应用程序都有自己的 IoC 设置，并为他们的东西做 DI，而无需真正关心彼此.
- I can't do DI only in the class library since the MVC app needs to inherit from NinjectHttpApplication to begin with.
- I can't do DI only in the MVC app - the class library is used by other libraries, after all, and the MVC app shouldn't know too much about the internals of the library anyway.
- I guess this is the only way out I can see: Independent IoC for both projects. The class library and the MVC app each have their own IoC setup and do DI for their stuff without really caring about each other.
有没有人有一些关于如何做这样的事情的最佳实践"或指导方针?我无法想象我是第一个遇到这种情况的人，知道这样做的正确"方法是什么肯定会很好......
Does anyone have some "best practices" or guidelines on how to do something like this? I can't imagine I'm the first person to end up in this situation, and it would sure be nice to know what the "proper" way to do this is...
谢谢！
推荐答案
我不知道 NInject，但除非它的工作原理与 Windsor、StructureMap 等大不相同.答案往往保持不变，因为有一些常见的 DI模式.考虑到这一点:
I don't know NInject, but unless it works vastly different than Windsor, StructureMap etc. the answers tend to stay the same, as there are some common DI patterns. With that in mind:
首先要意识到的是，DI 不依赖于特定的框架，例如 NInject 或 Windsor.它是一组要遵循的技术和设计模式.您可以使用所谓的Poor Man's DI 手动执行DI，但显然使用DI 容器会更好.
The first thing to realize is that DI isn't tied to a particular framework such as NInject or Windsor. It is a set of techniques and design patterns to follow. You can do DI manually using so-called Poor Man's DI, but obviously it gets much better with a DI Container.
为什么这是相关的?这是相关的，因为一旦您意识到这一点，推论是您应用程序的绝大多数代码应该不了解 DI 容器.
Why is this relevant? It is relevant because once you realize this, the corollary is that the vast majority of your application's code should have no knowledge of the DI Container whatsover.
那么您在哪里使用 DI 容器?它应该只用在 Composition Root 中，在您的情况下，它对应于 Global.asax.您可以在 this 中阅读更多相关信息所以答案 - 虽然这个问题是关于温莎的，但原则是一样的.
So where do you use the DI Container? It should only be used in a Composition Root, which in your case would correspond to Global.asax. You can read a bit more about this in this SO answer - although that question is about Windsor, the principle remains the same.
那么你的单元测试怎么样?他们也应该完全不知道 DI 容器.有关详细信息，请参阅此其他 SO 答案.
How about your unit tests then? They should be completely ignorant of the DI Container as well. See this other SO answer for more details.
DI 可以通过大量使用构造函数注入在您的库中实现.您不需要引用任何 DI 容器来执行此操作，但如果您使用 DI 容器来解析来自组合根的所有依赖项，则工作会轻松很多.
DI can be achieved in your library with copious use of Constructor Injection. You don't need to reference any DI Container to do that, but it makes life a lot easier if you use a DI Container to resolve all dependencies from the Composition Root.
这篇关于我应该在哪里使用 Ninject 2+ 进行注入(以及如何安排我的模块?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
