相关疑难解决方法(0)

我有一个问题,我将标记这个主观,因为这是我认为它演变成更多的讨论.我希望有一些好主意或一些思想家.我为这个冗长的问题道歉,但你需要了解背景.

问题基本上是:

• 您如何处理与IoC容器相关的具体类型？具体而言,谁负责处理它们,如果它们需要处置,以及这些知识如何传播到调用代码？

你要求它们是IDisposable吗？如果没有,该代码是否面向未来,或者是您不能使用一次性对象的规则？如果您对接口和具体类型强制执行IDisposable-requirements以便面向未来,那么它的责任是作为构造函数调用的一部分注入的对象？

编辑:我接受了@Chris Ballard的回答,因为它是我们最终接近的方法.

基本上,我们总是返回一个如下所示的类型:

public interface IService<T> : IDisposable
    where T: class
{
    T Instance { get; }
    Boolean Success { get; }
    String FailureMessage { get; } // in case Success=false
}

然后我们从.Resolve和.TryResolve返回一个实现此接口的对象,这样我们在调用代码中得到的内容总是相同的类型.

现在,实现此接口的对象IService<T>是IDisposable,应始终处理掉.程序员无法解析服务以决定是否IService<T>应该处置对象.

然而,这是至关重要的部分,无论服务实例是否应该被处置,知识被烘焙到实现的对象中IService<T>,因此如果它是工厂范围的服务(即,每次调用Resolve都会以新的服务实例结束) ),然后在处理IService<T>对象时处理服务实例.

这也使得支持其他特殊范围成为可能,例如汇集.我们现在可以说我们需要最少2个服务实例,最多15个,通常为5个,这意味着每次调用.Resolve都将从可用对象池中检索服务实例,或者构造一个新实例.然后,当处理IService<T>保存池化服务的对象时,服务实例将被释放回其池中.

当然,这使得所有代码看起来像这样:

using (var service = ServiceContainer.Global.Resolve<ISomeService>())
{
    service.Instance.DoSomething();
}

但它是一种干净的方法,无论使用何种服务或具体对象,它都具有相同的语法,因此我们选择它作为可接受的解决方案.

对于子孙后代,原始问题如下

冗长的问题来到这里:

我们有一个IoC容器,最近我们发现了一个问题.

在非IoC代码中,当我们想要使用一个文件时,我们使用了这样的类:

using (Stream stream = new FileStream(...))
{
    ... …