使用 container.RegisterAll<TService>() 时解析组件

Resolving components when using container.RegisterAll<TService>()

我在 类 中尝试注入依赖项时遇到问题。当我被困在这里时,我只是想了解更多关于简单注入和 DI 的知识。

所以这是我的主要方法:

static void Main(string[] args)
{
    var container = new Container();

    // Registrations here
    container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));

    container.Verify();

    Product p = new Product();
    p.TestLog();

    Console.ReadKey();
}

这是我的另一个 类:

public interface ISimpleLogger
{
    void Log(string content);
}

public class DebugLogger : ISimpleLogger
{
    public void Log(string content)
    {
        Debug.WriteLine(content);
    }
}

public class ConsoleLogger : ISimpleLogger
{
    public void Log(string content)
    {
        Console.WriteLine(content);
    }
}

public class Product
{
    public string Name { get; private set; }
    public decimal Price { get; private set; }
    public Product(string name, decimal price)
    {
        Name = name;
        Price = price;
    }

    private readonly ISimpleLogger[] loggers;

    public Product(params ISimpleLogger[] _loggers)
    {
        this.loggers = _loggers;
    }

    public void TestLog()
    {
        foreach (var item in loggers)
        {
            item.Log("testing...");
        }
    }

    public static List<Product> GetSampleProducts()
    {
        return new List<Product>
        {
            new Product { Name="West Side Story", Price = 9.99m },
            new Product { Name="Assassins", Price=14.99m },
            new Product { Name="Frogs", Price=13.99m },
            new Product { Name="Sweeney Todd", Price=10.99m}
        };
    }
}

1) 我在任何地方都看不到输出 "Testing..."。

2) 调试我的应用程序,当调用 Product 构造函数时,它不会注入依赖项,因此我的数组保持 0 项。

应该是什么?设置容器时配置错误?

问题很简单,您似乎已经正确配置了 container 但您没有要求它创建您的 Product 对象,因此能够注入依赖项。

不要自己 new 启动 Product,请 container 为您完成...

static void Main(string[] args)
{
    var container = new Container();

    // Registrations here
    container.RegisterAll<ISimpleLogger>(typeof(DebugLogger), typeof(ConsoleLogger));

    container.Verify();

    Product p = container.GetInstance<Product>();
    p.TestLog();

    Console.ReadKey();
}

我认为您还需要更改 Product 的构造函数以采用 IEnumerable<>

private readonly IEnumerable<ISimpleLogger> loggers;

public Product(IEnumerable<ISimpleLogger> loggers)
{
    this.loggers = loggers;
}

通过依赖注入,我们构建了组件的对象图。组件是我们应用程序中包含应用程序行为的 classes。这种对象图通常由长期服务组成。这些服务本身不应该包含任何状态。状态(或运行时数据)应该使用方法调用通过这个对象图推送。任何时候违反这个基本原则,都是自找麻烦。

您的 Product class 是一个实体。这是一个包含状态的短暂对象。防止 DI 库构建包含状态的对象。这会导致歧义和可维护性问题。

这已经发生在你的案例中,因为你想创建一个 Product class,你希望它是不可变的。所以这意味着它需要通过构造函数进行初始化。另一方面,您还希望将其依赖项注入构造函数,为此您有第二个构造函数。但是你只能调用一个构造函数;所以你的 Product 要么是没有依赖关系的有效产品,要么是有依赖关系的无效产品。

虽然您可以通过将两个构造函数合并在一起来解决这个问题,但这会导致同样多的麻烦,因为现在您将不得不要求 DI 容器为您构建此 Product,但 DI 容器知道与它必须提供的原语无关(在您的情况下是名称和价格)。

在我的项目中,我通常使用 anemic domain model. This means that my entities don't have any logic in them. Instead I use commands and queries 作为领域模型动词的定义。其他人不喜欢这样,喜欢将域逻辑作为域对象的一部分(尽管这两种模型并不相互排斥,但一些开发人员结合使用这些概念)。由于域逻辑有时需要与服务一起工作,这些实体显然需要提供这些依赖项。但是,这并不意味着您必须在此处使用构造函数注入。

这种情况下方法注入就方便多了。这意味着您的 Product class 将如下所示:

public class Product
{
    public string Name { get; private set; }
    public decimal Price { get; private set; }
    public Product(string name, decimal price) {
        Name = name;
        Price = price;
    }

    public void TestLog(ISimpleLogger[] loggers) {
        foreach (var item in loggers)
        {
            item.Log("testing...");
        }
    }
}

所以我们不是通过构造函数传递依赖关系,而是通过实际需要它的方法传递它。方法注入效果更好,因为:

  • 你的构造函数冲突消失了。您现在可以使用构造函数创建一个有效的实例,并在需要时提供所需的服务。
  • 它会阻止你的构造函数变得有很多依赖项。这将会发生,因为虽然实体上的大多数方法只需要一两个不同的服务,但实体上的所有方法可能需要十几个或更多的依赖项。这变得非常丑陋非常快。您经常会发现域对象上的方法之间没有太多的内聚性,这就是为什么我将此逻辑移到命令处理程序中的原因(但那是另一回事)。

当然,注入这些依赖项的责任现在转移到了调用此域方法的人(在您的情况下为 TestLog 方法)。但这通常不是问题,因为这个消费者将是一个普通的应用程序组件,您可以在其中再次应用构造函数注入。这是一个例子:

public class LogProductCommandHandler : ICommandHandler<LogProduct>
{
    private readonly IRepository<Product> productRespository;
    private readonly ISimpleLogger[] loggers;
    public LogProductCommandHandler(IRepository<Product> productRespository,
        ISimpleLogger[] loggers) {
        this.productRespository = productRespository;
        this.loggers = loggers;
    }

    public void Handle(LogProduct command) {
        Product product = this.productRepository.GetById(command.ProductId);
        product.TestLog(this.loggers);
    }
}

这个LogProductCommandHandler可以通过容器来解决。请注意,所有运行时数据 'flows' 通过此处的对象图。我们有这个包含运行时数据的 LogProduct 消息(命令)。它被传递给 Handle 方法。此消息包含一个 ProductId 值,它被传递到存储库的 GetById 方法,该方法将 return Product(再次运行时数据)。

还有一点。防止将事物列表注入消费者。注入 T[] 数组、IEnumerable<T>List<T> 通常意味着您正在泄漏实现细节。消费者不必知道或担心可能有多种实现的事实 - 在您的情况下 - 一个记录器。注入集合会使消费者复杂化,因为它必须迭代集合。不仅如此,依赖于该集合的每个消费者都需要迭代该集合。这不仅不必要地使所有这些消费者的代码复杂化,还会使您的代码更难更改。有时您会想要更改这些记录器的处理方式。也许您想继续记录到下一个记录器,即使第一个记录器抛出异常。我确定您知道如何编写此类程序;这不是一个很难解决的问题。但它会导致您对代码库进行彻底的更改以实现这一点。

相反,请使用 Composite design pattern。使用复合模式,您可以将一些抽象元素的集合隐藏在实现相同抽象的组件后面。 ISimpleLogger 的复合实现可能如下所示:

public sealed SimpleLoggerComposite : ISimpleLogger
{
    private readonly IEnumerable<ISimpleLogger> loggers;
    public SimpleLoggerComposite(IEnumerable<ISimpleLogger> loggers) {
        this.loggers = loggers;
    }
    public void Log(string message) {
        foreach (var logger in this.loggers) {
            logger.Log(message);
        } 
    }
}

这里我们将 foreach 循环移动到 SimpleLoggerComposite。现在我们可以注册 SimpleLoggerComposite 如下:

// Simple Injector v3.x
container.RegisterSingleton<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterCollection<ISimpleLogger>(
    new[] { typeof(DebugLogger), typeof(ConsoleLogger) });

// Simple Injector v2.x
container.RegisterSingle<ISimpleLogger, SimpleLoggerComposite>();
container.RegisterAll<ISimpleLogger>(
    new[] { typeof(DebugLogger), typeof(ConsoleLogger) });

现在应用程序的其余部分可以简单地依赖于 ISimpleLogger 而不是 ISimpleLogger[]。例如:

public class Product
{
    ...

    public void TestLog(ISimpleLogger logger) {
        logger.Log("testing...");
    }
}

现在您 TestLog 方法中的代码变得非常无聊。但这显然是一件好事。软件开发的诀窍是制作看起来非常简单的软件:-)