c# - 使用container.RegisterAll ()时解析组件

Question

尝试在类中注入依赖项时遇到问题。当我被困在这里时，我只是在尝试以了解有关简单注射和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项下。

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

Answer 1

通过依赖注入，我们可以构建组件的对象图。组件是我们应用程序中包含应用程序行为的类。此类对象图通常包含长期服务。这些服务本身不应包含任何状态。相反，应使用方法调用将状态（或运行时数据）推送通过此对象图。每当您违反此基本原则时，您都将面临麻烦。

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

在您的情况下，这已经发生了，因为您想创建一个Product类，您希望它是不可变的。因此，这意味着需要通过构造函数进行初始化。另一方面，您还希望将其依赖项注入到构造函数中，为此您需要第二个构造函数。但是您只能调用一个构造函数。因此您的Product要么是没有依赖项的有效产品，要么是带有依赖项的无效产品。

尽管您可以通过将两个构造函数合并在一起来解决此问题，但这将带来相同数量的麻烦，因为现在您将不得不要求DI容器为您构建此Product，但是DI容器对其原语一无所知必须提供（在您的情况下，名称和价格）。

在我的项目中，我通常使用anemic domain model。这意味着我的实体中没有任何逻辑。相反，我使用commands和queries作为域模型动词的定义。其他人则不喜欢这样，并且喜欢将域逻辑作为域对象的一部分（尽管这两种模型不是互斥的，但是一些开发人员将这些概念组合使用）。由于域逻辑有时需要与服务一起使用，因此这些实体显然需要提供这些依赖关系。但是，这并不意味着您被迫在此处使用构造函数注入。

在这种情况下，方法注入更为方便。这意味着您的Product类将如下所示：

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。请注意，所有运行时数据都在此处“流经”对象图。我们有此 LogProduct消息（命令），其中包含运行时数据。它传递给 Handle方法。该消息包含一个 ProductId值，并将其传递到存储库的 GetById方法，该方法将返回 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方法中的代码变得非常无聊。但这显然是一件好事。软件开发的诀窍是使看起来很简单的软件:-)