替代通过IOC容器 [英] Alternative to passing IOC container around

问题描述

我有以下具有几个依赖项的基类：

I had the following base class with several dependencies:

public abstract class ViewModel
{
    private readonly ILoggingService loggingService;

    public ViewModel(
        ILoggingService loggingService,
        ...)
    {
        this.loggingService = loggingService;
        ...
    }
}

在我的派生类中，我不想重复此基类构造函数中的所有参数，所以我这样做了：

In my derived class, I don't want to have to repeat all of the parameters in this base class constructor, so I did this:

public abstract class ViewModel
{
    private readonly IUnityContainer container;
    private ILoggingService loggingService;
    ...

    public ViewModel(IUnityContainer container)
    {
        this.container = container;
    }

    public ILoggingService LoggingService
    {
        get
        {
            if (this.loggingService == null)
            {
                this.loggingService = this.container.Resolve<IUnityContainer>();
            }

            return this.loggingService;
        }
    }

    ...
}

现在，我的派生类只需要将一件事传递给我的基类构造函数。我也有一个很好的效果，那就是仅在需要依赖项时才解决它们。

Now my derived classes only need to pass one thing to my base class constructor. I also have the nice effect of having my dependencies resolved only when they are needed.

但是，自那以后，我得知传递IOC容器是一个坏主意。牢记传递的许多服务已作为单例注册到我的IOC容器中，这是最佳的替代设计模式是什么？

However, I have since learned it is a bad idea to pass an IOC container around. What's the best alternative design pattern, bearing in mind that many of the services passed in have been registered with my IOC container as a singleton?

推荐答案

陈述时，应避免将容器传递过来。这就变成了一个持有袋子，在这里您不再能看到自己的依赖项，而且也无法轻易看到其中的包。

As you state, you should avoid passing the container around. This turns it into a "bag of holding", where you can no longer see what your dependencies are, and you can't easily see what's in the bag.

，如果您发现构造函数接受了太多的参数，那么这本身就是一种气味。在这种情况下，您经常会发现您的班级试图做太多事情（这违反了单一责任原则）。

Instead, if you find that your constructor takes far too many parameters, this is a smell by itself. In this case, you'll often find that your class is trying to do too many things (it's violating the single responsibility principle).

看看您的参数列表，然后查看是否可以将参数分组为较小的组。例如，如果您的构造函数使用 IEmailSender ， IEventLog 和 ILoggingService ，也许您真正需要的是 INotificationService ，它汇总了这三个依赖项。

Take a look at your parameter list, and see if you can group the parameters into smaller groups. For example, if your constructor takes IEmailSender, IEventLog and ILoggingService, maybe what you really need is an INotificationService which aggregates these three dependencies.

当然，有时您 do 的构造函数具有很多依赖性。在这种情况下，该类可能只是用来将这些东西收集在一起并连接起来的。在这种情况下，该类可能应该避免做任何实际的工作。

Of course, sometimes you do have a constructor with that many dependencies. In this case, the class is probably just used to gather these things together and to wire them up. If this is the case, the class should probably avoid doing any actual work.

这篇关于替代通过IOC容器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！