ViewModel Dispose 未被调用
我们使用 Ninject 和 Caliburn.Micro 来创建 MVVM WCF Silverlight 应用程序。我遇到的问题是视图模型的生命周期。
我创建了一个简单的 ninject 模块来绑定我的视图模型和 wcf 客户端。
public class IDCardModule : NinjectModule
{
public override void Load()
{
Bind<IIdCardManagerClient>().To<IdCardManagerClient>();
Bind<IDCard.SL.ViewModel.IIdCardViewModel>().To<IDCard.SL.ViewModel.IdCardViewModel>();
}
}
在我的 IIdCardViewModel 中,我要求它从 IDisposable 继承,因为我想注册和取消注册 wcf 事件和一些本地非托管引用。
然而,Dispose 永远不会被调用。
我考虑添加一个停用来像这样调用 dispose:
Bind<IDCardExclude.SL.ViewModel.IIdCardExclusionViewModel>().To<IDCardExclude.SL.ViewModel.IdCardExclusionViewModel>().OnDeactivation(
m => m.Dispose());
但这迫使我添加两件事,一个是在 IDCardModule 中检索对象并释放它的 Unload 重写:
var releaseMe = this.Kernel.Get<IIdCardViewModel>();
this.Kernel.Components.Get<Ninject.Activation.Caching.ICache>().Release(releaseMe);
以及 .InThreadScope() 或 .InSingletonScope() 到我的 Bind 方法在负载中。
是否有更简单的方法来强制停用特定对象?或者我应该研究另一个 IOC 框架?
我研究了 IStartable 并遇到了类似的问题。 另外,我深入阅读了 Nate 的文章,其中有一个激活块并将所有内容包装在 using 语句中。我的问题是我的视图模型可以长时间运行,我不相信他的解决方案在这里有效。同样,拥有一个休眠并调用 GC.Collect 的特殊线程,也不太对劲。
We are using Ninject with Caliburn.Micro to create a MVVM WCF Silverlight app. The issue I am having is with the life cycle of my view models.
I have created a simple ninject module to bind my view model and wcf client.
public class IDCardModule : NinjectModule
{
public override void Load()
{
Bind<IIdCardManagerClient>().To<IdCardManagerClient>();
Bind<IDCard.SL.ViewModel.IIdCardViewModel>().To<IDCard.SL.ViewModel.IdCardViewModel>();
}
}
In my IIdCardViewModel I have required it inherit from IDisposable, because I want to register and de-register for wcf events and some local unmanaged references.
However, Dispose is never being called.
I looked into adding a deactivation to call dispose like this:
Bind<IDCardExclude.SL.ViewModel.IIdCardExclusionViewModel>().To<IDCardExclude.SL.ViewModel.IdCardExclusionViewModel>().OnDeactivation(
m => m.Dispose());
But that forced me to add two things, an Unload override in my IDCardModule that retrieved the object and released it:
var releaseMe = this.Kernel.Get<IIdCardViewModel>();
this.Kernel.Components.Get<Ninject.Activation.Caching.ICache>().Release(releaseMe);
and either .InThreadScope() or .InSingletonScope() to my Bind method in Load.
Is there an easier way to force a deactivation on a specific object? Or should I look into another IOC framework?
I looked into IStartable and had similar issues.
As well, I read in-depth Nate's article where he has an activation block and wraps everything in a using statement. My issue there is that my view model can be long running and I don't believe his solution will work here. As well, having a special thread that sleeps and calls GC.Collect, doesn't smell right either.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
InTransientScoped 对象的生命周期不由 Ninject 管理。这意味着这些对象不会被处置和停用。如果您的视图模型被注入到另一个对象,您可以使用命名范围扩展中的 InParentScope。请参阅我的博客文章,了解 Ninject 的其他范围:http://www.planetgeek.ch/2010/12/08/how-to-use-the-additional-ninject-scopes-of-namedscope/
InTransientScoped objects lifecycle is not managed by Ninject. This means theese objects are not disposed and deactivated. If your view model is injected to another object you can use InParentScope from the named scope extension. See my blogpost about additional scopes of Ninject: http://www.planetgeek.ch/2010/12/08/how-to-use-the-additional-ninject-scopes-of-namedscope/
Lucas B,
我不确定这是否会对您有帮助,但我的对象也遇到了处理问题,在某些情况下会导致大量内存使用。我发现是事件订阅的问题。每次我订阅一个活动时,我都不会在活动结束后取消订阅。据我了解,如果一个对象仍在订阅事件,则它不会被销毁......所以一定要这样做( -= )。
希望这对您有所帮助,即使它与您的帖子并不完全相关。
Lucas B,
I am not sure if this is gonna help you but I had disposal problems with my objects too leading in some cases to huge memory use. I found out that it was a problem of event subscription. Each time I was subscribing to an event, I was never unsubscribing to it after the event completion. As far as I understand, an object is not destroyed if it is still subscribing to an event ... So be sure to do so ( -= ).
Hope this help even if it is not totally related to you post.