dependency-injection - 依赖注入(inject) + 环境上下文 + 服务定位器

Question

最近我阅读了很多关于应用程序设计模式的资料:关于 D​​I、SL 反模式、AOP 等等。这样做的原因——我想在设计上做出妥协:松散耦合、干净且易于使用。 DI 看起来几乎像是一种解决方案，除了一个问题:导致构造函数或属性污染的横切和可选依赖项。因此，我为此提出了自己的解决方案，我想知道您对此有何看法。

Mark Seemann(DI 书的作者和著名的“SL is anti-patter”声明)在他的书中提到了一种称为 Ambient Context 的模式。尽管他说他不太喜欢它，但这种模式仍然很有趣:它就像古老的好单例，只是它有作用域并提供默认值，所以我们不必检查 null。它有一个缺陷 - 它不知道也无法知道它的范围以及如何处置自己。

那么，为什么不在这里应用服务定位器呢？它可以解决环境上下文对象的范围界定和处置问题。在你说它是反模式之前:它是你隐藏契约(Contract)的时候。但在我们的例子中，我们隐藏了 OPTIONAL 契约(Contract)，所以 IMO 还不错。

这里有一些代码可以说明我的意思:

public interface ILogger
{
    void Log(String text);
}

public interface ISomeRepository
{
    // skipped
}


public class NullLogger : ILogger
{
    #region ILogger Members

    public void Log(string text)
    {
        // do nothing
    }

    #endregion
}

public class LoggerContext
{
    public static ILogger Current
    {
        get
        {
            if(ServiceLocator.Current == null)
            {
                return new NullLogger();
            }
            var instance = ServiceLocator.Current.GetInstance<ILogger>();
            if (instance == null)
            {
                instance = new NullLogger();
            }
            return instance;
        }
    }
}

public class SomeService(ISomeRepository repository)
{
    public void DoSomething()
    {
        LoggerContext.Current.Log("Log something");
    }
}

编辑:我意识到不问具体问题与堆栈溢出设计相冲突。因此，我会将最好地描述为什么这种设计不好或更好地提供更好的解决方案(或者可能是补充？)的帖子标记为答案。但是不要建议 AOP，它很好，但是当你真的想在代码中做一些事情时，它不是一个解决方案。

编辑 2:我添加了对 ServiceLocator.Current 为 null 的检查。这就是我打算让我的代码执行的操作:在未配置 SL 时使用默认设置。

Answer 1

您可以使用手工制作的装饰器或某种拦截(例如 Castle DynamicProxy 或 Unity's interception extension )添加横切关注点。

因此您根本不必将 ILogger 注入(inject)到您的核心业务类中。