带有构造函数参数的子类的工厂依赖注入

Question

我有一个使用Ninject进行DI的应用程序，并且具有以下构造：

public class SomeServicHost
{
    private ISomeService service;

    public SomeServicHost(ISomeService service)
    {
        this.service = service;
    }

    public void DoSomething(int id)
    {
        // Injected instance
        this.service.DoWhatever("Whatever");

        // Without injection - this would be how it would be instantiated
        var s = new SomeService(new Repo(id));
        s.DoWhatever("Whatever");
    }
}

interface ISomeService
{
    void DoWhatever(string id);
}

class SomeService : ISomeService
{
    private IRepo SomeRepo;

    public SomeService(IRepo someRepo)
    {
        this.SomeRepo = someRepo;
    }

    public void DoWhatever(string id)
    {
        SomeRepo.DoSomething();
    }
}

interface IRepo
{
    void DoSomething();
}

class Repo : IRepo
{
    private int queueId;

    public Repo(int queueId)
    {
        this.queueId = queueId;
    }

    public void DoSomething()
    {
        // Whatever happens
    }

因此，正常的注射将无法正常工作。 我需要一家工厂。 所以我可以做类似的事情：

interface IServiceFactory
{
    ISomeService GetService(int id)
    {
        return new SomeService(new Repo(id));
    }
}

我已经敏锐地知道了。 但是，如果这样做，我将失去所有的DI优势，例如生命周期管理，或者将一个实现换成另一个实现。 有没有更优雅的方式做到这一点？

Answer 1

而不是做

new SomeService(new Repo(id));

你可以做

IResolutionRoot.Get<Repo>(new ConstructorArgument("id", id));

IResolutionRoot是内核的类型解析接口，您可以将其构造函数注入。 这将使您从您所谓的“ DI善良”中受益。 请注意，您可能还想使用ninject.extensions.contextpreservation扩展名。

@Simon Whitehead已经指出了ninject.extensions.factory ，它可以帮助您消除样板代码，并且基本上可以完全按照我上面的描述进行操作。

通过将IResolutionRoot.Get<>调用移到另一个类（ IResolutionRoot.Get<> ...），您可以从实例中减轻SomeService的负担。 ninject.extension.factory正是这样做的。 由于扩展不需要实际的实现，因此您甚至可以节省一些单元测试！ 此外，如果SomeService扩展并且需要DI管理的更多依赖项，该怎么办？ 不用担心，因为您正在使用内核实例化该类，所以它将自动运行，并且IoC将按需管理您的依赖项。 如果您不打算使用DI进行实例化，那么最后可能只需要使用很少的DI。

正如@ zafeiris.m所指出的，这称为服务定位器。 并且通常也称为反模式。 没错！ 只要可以实现更好的解决方案，就应该这样做。 在这里你可能做不到。 可以说这更好，所以无论人们怎么说，都坚持使用最佳解决方案。

可能存在减少服务位置使用量的方法。 例如，如果您有一个业务案例，例如“ UpdateOrder（id）”，则该方法将为该ID创建一个服务，然后为该ID创建另一个服务，然后为该ID创建记录器，..您可能需要更改它创建一个将ID作为可继承的构造函数参数的对象，并将特定于ID的服务和记录器注入该对象，从而将3个工厂/服务定位器调用减少为1。

Answer 2

对工厂来说，按照您的描述进行操作对我来说似乎很好。 这就是它们的目的，当您拥有只能在运行时根据某些运行时值（例如您的案例中的id ）实例化的服务时，工厂就是要走的路。

但是，如果这样做，我将失去所有的DI优势，例如生命周期管理，或者将一个实现换成另一个实现。

DI不能替代工厂。 您需要两个世界都可以带来灵活，松散耦合的设计。 工厂用于新建依赖关系，他们知道如何创建依赖关系，使用什么配置以及何时处置它们，并且如果要交换实现，您仍然只更改一个地方：只是这次是工厂，而不是DI组态。

最后一点，您可能会想使用服务定位器反模式 ，如另一个答案中所建议。 您将最终得到较差的设计，更少的可测试性，更少的清晰度，可能与您的DI容器紧密结合等等。 您使用工厂的想法要好得多。 （ 这里有更多示例，类似于您的示例）。