Question

我刚刚读到了控制反转（IOC），这让我感到困扰，似乎它让内存管理变得痛苦。当然，似乎ioc主要用于垃圾收集环境（Net，Java，Scripting），而我关注的是非gc设置。

我担心的是，IOC在某种程度上违背了RAII，因为我们将资源生命周期与对象生命周期分离开来。这增加了复杂性是否会困扰其他人？真正的问题是，有什么技术可以让事情顺利进行？

Answer 1

由于这个原因，我已经创建了自己的IoC容器，它返回（在C＃/ .NET中）一次性服务包装器，在处理完毕后，将对服务“做正确的事”。

是吧：

什么都不做，何时：
- 该对象未实现IDisposable
- 不是容器范围的（在这种情况下，容器将跟踪它并多次返回同一个对象，当容器被丢弃时，对象也将如此）
- 没有汇集
- 它不是单一作用域的（与容器作用域相同，但容器层次结构会将单例作用域服务存储在最顶层的容器中）
处置服务（具有工厂范围，并实现IDisposable）
将其归还池中

这意味着使用我的服务的所有代码都在使用块内，但意图更清晰，至少对我而言：

using (var service = container.Resolve<ISomeService>())
{
    service.Instance.SomeMethod();
}

基本上它说：解析服务，在服务实例上调用SomeMethod，然后处理服务。

由于消费者无法获知是否处置服务实例，因此可以选择完全忽略IDisposable实现，或者处理实现IDisposable的所有服务。这对我来说都不是一个好的解决方案。第三种选择是将服务实例包装在一个对象中，该对象知道在处理包装器后如何处理该服务。

Answer 2

是和否。 IoC不会将资源生命周期与对象生存期分离，它将方法调用范围与对象生存期分离 - 您经常希望在方法结束时销毁的对象存在，直到进行另一个IoC调用。因此，您要么必须将方法的局部移动到类范围内，并确保没有方法可重入，要么采用其他方法，例如传递额外的“环境”以允许对象拥有对象，并销毁在随后的IoC方法调用中。如果你想要一个通用的事件驱动系统，这两种方法都会变得非常复杂 - 要么你的模型最终必须自己实现显式递归和迭代，要么你的简单RAII C ++代码很快变成一个非常复杂的回调嵌套 - 我放弃了这么复杂在C ++和RAII上开始使用kin。

Answer 3

我能想到的第一件事就是SmartPointers。和模板参数。但我不确定模板参数是否算作IOC技术，尽管我认为它们应该。至少这些可以减轻国际奥委会的一些问题，但并没有完全出售这个想法。

可以反转控制和RAII一起玩吗？

3 个答案: