我们在应用程序中使用Castle Windsor的类型化工厂,并发现,虽然它们确实对应用程序“隐藏”了IoC容器,但一些抽象肯定会泄漏出来。也就是说,工厂必须实现release方法,以便可以安全地处置或以其他方式退役已解析的实例。毕竟,你永远不会知道组件的“负担”中的某些东西,即下游依赖项,什么时候会引入可能需要新语义的东西。因此,您总是假设(实际上)从类型化工厂返回的所有内容都是IDisposable
--也就是说,您应该跟踪它并返回它。出于这个原因,我们喜欢返回其Dispose
方法将其返回到工厂的IReference<T>
对象,以便强制执行此行为,而不是依赖于陌生人友好地调用该release方法。
然而,在许多情况下,我们非常确信服务类型将不需要这些语义。我们知道Castle Windsor甚至不会费心跟踪真正的瞬态对象,没有下游负担。垃圾收集器会做得很好。在这种情况下,我们会对没有返回方法的工厂感到满意。用户可以让垃圾收集来做它自己的事情。
我们想要做的是,在所有类型化工厂都被注册之后,检查内核和类型化工厂设施的注册,看看是否违反了这些假设。也就是说,对于任何类型工厂方法发出警告,该方法返回的类型不具有IDisposable
语义,但最终被注册为具有该语义的负担。(可能有必要对此进行自定义;例如,取决于应用程序范围的单例对象,或者可以接受按请求的对象)。
用来开始查询和/或执行这些约定的最佳公共接口是什么?或者我们是否应该停止使用如此多的类型化工厂?
发布于 2011-06-13 11:16:03
不确定,但我认为可配置的版本策略就是您想要的,特别是这里提到的No Tracking版本策略:http://www.primordialcode.com/blog/post/castle-windsor-transient-objects-and-release-policies
发布于 2011-06-13 13:36:26
Krzysztof在this post中显示了类似的内容。它展示了如何对您的注册代码进行单元测试,以确保在容器中正确注册所有内容。
https://stackoverflow.com/questions/6326301
复制相似问题