将 Spring.Net IoC 替换为另一个容器（例如 Ninject）
我很好奇是否可以用 Ninject 来替换 Spring.Net 的内置 IoC 容器。我们的团队在其他项目中使用 Ninject 进行 IoC，因此如果可能的话，我想继续使用该容器。
这可能吗？有人写过 Ninject-Spring.Net 适配器吗？
编辑
我喜欢 Spring.Net 包的许多部分（数据访问、事务等），但我不太喜欢依赖注入容器。我想用 Ninject 替换它，
谢谢
I'm curious to know if it's possible to replace Spring.Net's built-in IoC container with Ninject. We use Ninject on my team for IoC in our other projects so I would like to continue using that container if possible.
Is this possible? Has anyone written a Ninject-Spring.Net Adapter??
Edit
I like many parts of the Spring.Net package (the data access, transactions, etc.) but I don't really like the dependency injection container. I would like to replace that with Ninject
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我无法具体谈论将 Spring.NET 转换为 Ninject，但一般来说，所有应用程序代码都应编写为DI 容器不可知。
考虑 DI 容器的最佳方式是好莱坞原则。用 DI 术语来说，就是，不要调用 DI 容器，它会调用您。
换句话说，DI 的最佳应用是使用简单的模式，例如构造函数注入和抽象工厂。
大多数值得信赖的 DI 容器本质上都理解这些模式，因此不需要特殊的、特定于 DI 容器的跳过障碍。
这也意味着，理想情况下，您的应用程序中的单个文件中应该只包含 DI 容器特定的代码。这个地方称为组合根，这是 DI 容器连接整个对象图并避开的地方。
如果遵循这一原则，您可以轻松地将一个 DI 容器更换为另一个。
以下帖子有更多详细信息：
I can't talk specifically about converting Spring.NET to Ninject, but in general, all application code should be written to be DI Container-agnostic.
The best way to think about DI Containers is the Hollywood Principle. In DI terms, it becomes, don't call the DI Container, it'll call you.
In other words, the best application of DI is to use simple patterns such as Constructor Injection and Abstract Factory.
Most DI Containers worth their salt inherently understand these patterns, so no special, DI Container-specific, jumping through hoops should be needed.
This also means that ideally, you should only have DI Container-specific code in a single file in your application. This place is called the Composition Root, and this is where the DI Container wires up the entire object graph and gets out of the way.
If you follow this principle, you can easily exchange one DI Container for another.
The following posts have more details:
杰弗里，你能举例说明你正在尝试做什么吗？我不明白你的意思，为什么/在哪里/如何混合这两个容器。如果您的代码完全与容器无关，那么使用任一容器进行连接都不会有任何问题。
Jeffrey, can you please provide an example of what you are trying to do? I do not see your point, why/where/how you want to mix the 2 containers. If your code is entirely container-agnostic, then you won't have any problems to use either container for doing the wiring.
我的意思是我在其他答案中所说的一切。然而，我也意识到，如果您当前使用Spring.NET作为服务定位器（即您的代码库中遍布查询容器的代码），那么这个答案可能不是很有帮助。
如果是这种情况，您可能会发现 Common Service Locator 项目很有帮助。它是一个开源项目，试图抽象出特定的服务定位器，将它们全部隐藏在一个公共接口后面。
虽然他们似乎没有 Ninject 实现，但他们确实有 Spring.NET 实现，所以也许这可以让你成功一半。
根据记录，我认为服务定位器是一种反模式，并且发现公共服务定位器是对错误问题的错误答案。在我看来，这是完全多余的，但作为中间步骤，它可能对您有所帮助。
I meant everything I said in my other answer. However, I also realize that if you currently use Spring.NET as a Service Locator (i.e. you have code sprinkled all over your code base that queries the container), that answer may not be very helpful.
If this is the case, you may find the Common Service Locator project helpful. It is an open source project that attempts to abstract away specific Service Locators, hiding them all behind a common interface.
While they don't seem to have a Ninject implementation, they do have a Spring.NET implementation, so maybe that can take you halfway there.
For the record, I consider Service Locator an anti-pattern, and find that the Common Service Locator is the wrong answer to the wrong problem. In my eyes, it is utterly redundant, but it may be helpful to you as an intermediate step.