在多个解决方案中实现依赖注入

时间:2014-10-24 06:45:37

标签: c# dependency-injection unity-container

我们拥有15个解决方案,每个解决方案都包含许多自己的项目。然而,所有解决方案都共享一些称为“模型”的常见项目。但是,由于每个解决方案都连接了自己的对象图,因此会导致Model项目的注册重复15次。

防止这种重复的最佳方法是什么?

示例:

解决方案-A

模型

public class Account
{
    public Account()
    {
        var a=Resolve<IEmailer>();
    }
}

在构造函数中添加上面的代码会强制我在解决方案的所有启动项目中注册依赖项,如果它们引用了上面的类。某些解决方案需要Account类但不需要IEmailer,但仍需要在该解决方案中注入IEmailer

1 个答案:

答案 0 :(得分:4)

在启动项目中注册所有内容实际上是一件好事。这个常见的地方称为Composition Root,它允许您最小化项目之间的引用数量,正如here所解释的那样。

你要防止的另一件事是让你的代码(除了你的作品根目录之外的任何东西)依赖于DI库或你的DI库的抽象。因此,不要从构造函数内部调用Resolve,而是将类的任何依赖项注入到该类的构造函数中。例如:

public class Account
{
    private readonly IEmailer emailer;

    public Account(IEmailer emailer)
    {
        this.emailer = emailer;
    }
}

从代码中回调到容器中有many advantages

请注意,您的容器是用于构建服务的对象图。如果Account是实体,则从容器中解析该实体不是usual and advised thing to do

关于您遇到的多解决方案问题:由于您正在使用的共享项目,最好不要将其作为项目引用,但要将其作为一个具有自己的发布周期的独立项目。在这种情况下,其他项目可能取决于您发布的程序集(例如,使用您自己的本地NuGet服务器)。

但除此之外,由于这是一个可重用的项目,请确保程序集成为DI friendly library。如果要进行任何引导,并且您希望防止在解决方案中重复此操作,请创建一个单独的引导项目。这个bootstrapping项目引用了可重用的库,它引用了你的Unity容器。这样,您的库仍然完全独立于使用的DI库,同时防止在整个解决方案中重复引导逻辑。