>不要使用Castle Windsor来实现IDependencyResolver.在ASP.NET MVC 4中这仍然是正确的吗？
>如果是1的话.任何其他DI容器(Unity,StructureMap)都有与Castle Windsor相同的问题吗？我可以使用任何替代品吗？
非常感谢
编辑
听我说Castle Windsor不应该用来实现IDependencyResolver.我已决定使用其他一些DI容器,例如StructureMap
解决方法
在我看来,迈克哈德洛在这个问题上有点过于苛刻,而且许多其他人都没有真正考虑过为什么而加入了这个行列.
是的,Castle Windsor确实拥有一个名为Pooled的特定对象生活方式(即终身管理对象),通常需要您在其上调用Release.在使用这种生活方式时,您可能不应该使用IDependencyResolver,因为它不提供对此Release方法的访问(尽管也有方法).
但是,我觉得在Web应用程序中使用这种生活方式通常很糟糕,您应该使用PerWebRequest生活方式,它将在Web请求结束时自动释放对象.如果这是你正在使用的,那么使用Castle Windsor的IDependencyResolver没有问题.
为什么我认为哈德洛太腐蚀？好吧,因为他的全部论点都基于此：
“这是正确的,没有’释放’方法.你可以从你的IoC容器中提供服务,但是没有办法清理它.如果我要在Suteki商店使用它,我会有一个史诗般的内存泄漏. “
然后,他继续参考KrzysztofKoźmic关于生活方式管理的文章,但忽略了参考他将在这里做的后续文章：
http://kozmic.net/2010/08/27/must-i-release-everything-when-using-windsor/
请注意他在这里说的话：
“正如我在上一篇文章中提到的那样,Windsor将跟踪你的组件,这是用户普遍存在的误解,为了正确释放所有组件,他们必须在容器上调用Release方法.”
他继续谈论其他各个方面,但总的来说,我认为大多数人都不会使用需要在Web应用程序中处理的Pooled或Transient对象.如果你这样做,那么你应该知道不要使用IDependencyResolver.否则,你应该没有问题.
我知道我可能会从别人的争论中得到很多的悲痛,但我根本不认为这是世界问题的终结,像Hadlow这样的人似乎认为它是,因为有很多选择,甚至是你需要打电话给Release.
除此之外,使用需要调用Release的生活方式意味着为开发人员提供额外的工作.您现在必须管理对象生存期并记住处置对象,否则会导致内存泄漏.在我看来,这基本上使垃圾收集的好处无效.我只使用不需要处理的东西的瞬态对象,我从不使用池化对象.
顺便说一句,我可能是错的,但我不认为任何其他容器有这个问题.这让我得出的结论是,当其他每个容器似乎都没有问题时,Windsor就会被打破,而不是MVC.温莎喜欢顽固地坚持其现实版本,所以YMMV.
