Question

我想像我这样使用我的子类：

throw new MyCustomException()

而且无论何时调用它，我都希望用相关id包装它，它假定由服务注入。我想将它注入基类，以避免像那样写

throw new MyCustomException(correlationID)

但我不知道在应该使用构造函数注入的情况下如何做到这一点。

换句话说，我想将依赖注入无参数构造函数。像这样的东西

class MyBaseException()
{
    private IWorkingContext workingContext;
    public MyBaseException()
    {
        this.workingContext = workingContext;
    }
}

是的，我知道通常我需要这样做：

public MyBaseException(IWorkingContext workingContext)

但是想要在没有参数的情况下调用这个构造函数MyBaseException（IWorkingContext workingContext），所以最后我可以像MyCustomException（）一样使用我的子类，并将workingContext包装在其中。

我的温莎注册：

container.Register(Component.For<IWorkingContext>().ImplementedBy<WorkingContext>().LifeStyle.PerWebRequest)

我尝试过这种方法：

var containerAccessor = HttpContext.Current.ApplicationInstance as IContainerAccessor;
var container = containerAccessor.Container;
var operationContext = container.Resolve<IWorkingContext>();

但它不起作用（新对象由Windsor创建）。

Answer 1

当您new异常时 - 或任何类别 - 它不是由您的IOC容器管理的，因此它无法帮助您丰富您的异常类。

你可以做几件事，但其中一些质量有问题：

在例外的构造函数中使用服务定位器模式（非常令人讨厌）
使用工厂方法/类 - 在IOC容器中注册并依赖IWorkingContext - 这实际上会为您提供异常实例以引发堆栈。这仍然意味着您的异常将在依赖项中接受构造函数，但抛出异常的类不知道或不需要知道这一点。（我会推荐这种方法）
一个专门的类，生活在你的域的外围，旨在捕获并随后丰富任何冒泡堆栈的异常。这有以下几个原因：
- 错误的实现会让您丢失异常的上下文（主要是堆栈跟踪信息）
- 您现在几乎强制执行每个组件以忽略异常，因为您迫切需要针对日志记录的异常上下文或不需要上下文。
质疑您的整个方法。为什么不在日志时使用上下文来丰富异常，而不是在异常时添加此元数据？

就个人而言，我认为2是最可行的选择，但如果您在整个应用程序中有很多不同的自定义异常，它可能会迅速失控。我总是会看4，不管你选择哪个选项，因为有时候你试图解决的问题是错误的问题。

将dependecy注入无参数构造函数（Windsor容器）

1 个答案: