0

使用 Simple Injector，是否有 StructureMap 的等价物（通过反射Container.With("CustomerId").EqualTo(100).GetInstance<Customer>()查找属性）？CustomerId

4

1 回答 1

1

在 Simple Injector 中没有与此等价的功能。原因是这样的构造通常会导致Service Locator 反模式，并且会导致由于使用魔术字符串而导致的脆弱配置。

因此，一般（独立于容器）的建议是使用抽象工厂（正如 Mark Seemann 解释的那样）。应用程序可以依赖抽象工厂而不是使用容器。您将责任转移到工厂。您仍然需要在工厂内创建该依赖项。此示例显示了一个解决方案：

// Part of Composition Root
private class SomeObjectFactory : ISomeObjectFactory
{
    private readonly Container container;

    public SomeObjectFactory(Container container)
    {
        this.container = container;
    }

    public SomeObject Create(int someValue)
    {
        return new SomeObject(someValue,
            this.container.GetInstance<IOtherDependency>()
        );
    }
}

虽然这可行，但Create每次更改构造函数时都必须更改该方法SomeObject。

因此，一般而言，我的建议是当您的目标是进行自动装配（容器为您注入所有依赖项）时，避免在同一个构造函数中将原始值（例如 int 和字符串）与服务依赖项混合。尽管某些容器为注册和解析包含原始值的类型提供了更多支持，但它总是导致需要更多维护且更脆弱的 DI 配置。

相反，请尝试：

  1. 将原始值包装在可以注入的类中。即注入一个IConnectionManager而不是一个string connectionString。
  2. 将原始值提升为属性。使用 Simple Injector，这允许您进行显式属性注入（通过使用 注册初始化委托RegisterInitializer），从而实现编译时可验证的连接。

此规则的唯一例外是当您有某种约定优于配置的方法时，该方法使您能够自动检测某种原始值，如此处所示。不过，我认为你必须好好看看你的设计。当相同的原始（配置）值被注入到多个服务中时，您可能会遗漏一个抽象。在这种情况下，应用#1。

但是，此建议尤其适用于配置值。您正在处理运行时值。但是，在处理运行时值时，使用属性仍然可用：

// Part of Composition Root
private class SomeObjectFactory : ISomeObjectFactory
{
    private readonly Container container;

    public SomeObjectFactory(Container container)
    {
        this.container = container;
    }

    public SomeObject Create(int someValue)
    {
        var instance = this.container.GetInstance<SomeObject>();
        instance.SomeValue = someValue;
        return instance;
    }
}

通过提升SomeValue到一个属性，我们允许容器在运行时值的注入上使用自动装配SomeObject并启用编译时支持someValue。

然而，使用这样的工厂可能看起来有点冗长，而其他人可能宁愿注入一个Func<T>委托：

container.RegisterSingle<Func<int, SomeObject>>(someValue =>
{
    var instance = this.container.GetInstance<SomeObject>();
    instance.SomeValue = someValue;
    return instance;
});

在这种情况下，您的应用程序逻辑可以依赖于Func<int, SomeObject>可以注入构造函数的委托。这消除了很多仪式感，缺点是在应用程序的设计中失去了一些表现力，因为Func<int, SomeObject>它的表现力要低得多SomeObject Create(int someValue)。

但是，在您的特定情况下，您似乎正在解析实体。正如 Mark Seemann在这里解释的那样，这可能不是最好的做法。此外，让容器创建您使用运行时 id 提供的实体对我来说似乎很奇怪，因为通常会从数据库中检索具有 Id 的实体。

您可能正在应用领域驱动设计，这就是为什么您需要这些服务依赖于您的实体。与其进行构造函数或属性注入，不如考虑使用方法注入。只需添加实体方法所需的依赖项作为方法参数。然后，您可以在从命令处理程序调用该方法时传递这些依赖项。在这种情况下，命令处理程序仍然可以使用普通的旧构造函数注入。当我第一次看到这个（我相信这是 Jimmy Nilsson 的演讲）时，我觉得它与我所知道的一切相矛盾。然而，一段时间后，我开始发现这实际上是一个非常好的解决方案（对于这个特定场景）。

于 2012-12-22T10:06:38.547 回答