在.NET中的同一解决方案中使用两个IoC容器的缺点? [英] Downsides of using two IoC containers in same solution in .NET?
问题描述
我正在开发一个项目，该项目使用了其他开发人员的一组库，这些库使用 structuremap 作为IoC容器.[我有代码库]
I am working on a project which uses a set of libraries from some other developer which uses structuremap as the IoC container. [I have the codebase with me]
我们要在其中合并这些库的应用程序使用统一容器.
The application in which we are incorporating these libraries uses unity container.
在同一解决方案中拥有两个容器框架是否有不利之处?我想将所有内容移到同一个IoC容器中，但是如何证明额外的努力呢?
Is there a downside to having two container frameworks in the same solution? I want to move everything over to the same IoC container but how do I justify the extra effort?
推荐答案
在同一个 solution 和同一个 application 中拥有多个容器库是有区别的，因为一个解决方案可以包含多个可运行的应用程序.
There is a difference between having multiple container libraries in the same solution vs. the same application, since a solution can consist of multiple runnable applications.
All components should be wired in the application's start-up path, a.k.a. the Composition Root:
Composition Root是应用程序中模块组成在一起的(最好是)唯一位置.
A Composition Root is a (preferably) unique location in an application where modules are composed together.
与构造函数注入一起使用，合成根"模式使您的应用程序完全松散耦合" ，并使您的应用程序代码与DI容器分离.
Together with the use of Constructor Injection, the Composition Root pattern keeps your application completely loosely coupled, and keeps your application code decoupled from your DI Container.
根据成分根模式，因此应用程序的其他任何部分均不应依赖DI容器.您使用的库确实存在问题，因为这会迫使您进入某个DI容器.更好的解决方案是使库 DI友好
According to the Composition Root pattern, no other parts of an application should therefore depend on a DI Container. The fact that the libraries that you use do, is problematic, because this forces you into a certain DI Container. A better solution is to make the libraries DI-friendly.
在同一解决方案中具有多个容器库有一些缺点:
There are a few downsides to having multiple container libraries in the same solution:
- 您必须学习两个不同的DI容器库，每个库都有其局限性和怪异之处
- 在开发停止.
最重要的是，在同一应用程序中使用多个容器库有一些缺点:
On top of that, there are a few downsides to using multiple container libraries in the same application:
- 当单个对象图由来自不同容器的应用程序组件构成时，可能会产生复杂性.可视化对象图并验证其正确性可能很困难.
- 如果从这两个容器中解析出某个组件，则可能会导致 Torn生活方式
这并不是说您在同一个解决方案或应用程序中绝对不应有多个容器.例如，您可能有两个容器作为临时解决方案，因为您要从一个库移到另一个库，但是要进行大规模的迁移则需要太多工作.理想情况下，在那种情况下，您一次可以迁移一个应用程序，但即使那样也可能一次也无法执行.
That's not to say that you should never have multiple containers in the same solution or application. For instance, you could have two containers as a temporary solution, because you are moving from one library to the next, but a big bang migration is too much work. Ideally, you would in that case migrate one application at the time, but even that could be too much to chew off at once.
具有两个容器的另一个常见方案是，您正在运行的应用程序框架在内部使用DI容器来构建其服务.这些框架的常见示例是ASP.NET Core和NServiceBus.在那种情况下，为了清楚地区分，我通常谈论框架的配置系统而不是其内部容器，因为这基本上就是框架.它是一个容器，是一个实施细节.
Another common scenario where having two containers is fine, is when the application framework you are running is using a DI Container internally to build up its services. Common examples of these frameworks are ASP.NET Core and NServiceBus. In that case, to make the distinction clear, I typically talk about the framework's configuration system instead of its internal container, since that's what it basically is. It being a container, is an implementation detail.
在这种情况下，您可以按原样保留内置的配置系统"来解析框架组件，并使用您选择的DI容器构建应用程序组件的对象图.
In that case you can leave the built-in 'configuration system' as-is to resolve framework components, and use your DI Container of choice to build object graphs of application components.
这篇关于在.NET中的同一解决方案中使用两个IoC容器的缺点?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
