Xamarin、Autofac、NavigationService 和 BeginLifetimeScope

Question

关于在 xamarin 应用程序中使用 autofac 以及何时使用它们的生命周期范围的初学者问题。

正如 autofac 文档 (https://nblumhardt.com/2011/01/an-autofac-lifetime-primer/) 引用的本文 (http://docs.autofac.org/en/latest/lifetime/) 中提到的，他们在不从根容器解析而是使用单独的生命周期范围和考虑工作单元方面做出了很多努力，因为 autofac 持有引用即使它们在创建它们的范围被释放之前不再使用，也不会被使用，因此存在内存泄漏的危险。

但是，在开发 Xamarin 应用程序并查找示例时，我没有找到这种用法的示例，同时考虑到使用 IoC 容器作为服务定位器 anitpattern，何时使用它？ (https://xamarinforms.wordpress.com/tag/dependency-injection/)

这些文章显示了在 xamarin 应用程序中设置导航并解析必要的 View 模型并将它们设置为页面的绑定(bind)上下文的“最佳实践”示例:
https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/navigation/和 https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/mvvm/#automatically_creating_a_view_model_with_a_view_model_locator
不确定这是否是最佳实践，或者只是以 xamarin 形式做事的最佳方式。

但是，现在当这些 View 模型被 autofac 实例化并且其中一个模型依赖于一次性类时会发生什么？

当请求 viewModel 时，会解析与页面匹配的新实例并放入导航堆栈。因此，当导航页面时，堆栈会越来越大，autofac 会保留对所有一次性对象的引用，并且在应用程序的生命周期中(一切都从主容器中解析，不使用单独的范围)，这可能会持续很长时间，是这里有遇到内存问题的风险吗？如果这些未使用的对象仍有被引用的风险，那么这些未使用的对象何时会被垃圾回收？可能我对它的实际工作原理有一些了解，或者在使用中犯了一个错误，但请注意 https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/navigation/ 中的 InternalNavigateToAsync 方法是如何工作的。只是在导航到另一个页面时不断将页面添加到堆栈中..

PS。附带说明一下，这看起来不错(scope.Resolve):

using(var scope = container.BeginLifetimeScope())
{
  for(var i = 0; i < 100; i++)
  {
    var w = scope.Resolve<Worker>();
    w.DoWork();
  }
}

这来自( http://docs.autofac.org/en/latest/register/registration.html 以及其他一些地方......):

using(var scope = container.BeginLifetimeScope())
{
  var reader = container.Resolve<IConfigReader>();
}

在autofac文档中使用，我想最后一个是错字？？ (container.Resolve 而不是 scope.Reslove，它周围有一个无用的(？)范围 block ，无论如何都在这个范围 block 内从主容器解析......

Answer 1

遗憾的是，AutoFac 和其他所谓的“IOC”容器和/或框架往往夸大了它们的功能。它们也不是很像 IOC。

如果我创建这个普通的类:

public class NonDerivedClass
{
    using (var scope = contaner.BeginLifetimeScope())
    {
        var reader = container.Resolve<IConfigReader>();
    }
}  

...然后我实例化、使用并最终销毁 NonDerivedClass，读者怎么知道也被销毁了？我的意思是，根据 C#，使用什么机制？没有一个。 未引发任何事件 当对象超出范围并有资格进行垃圾回收时

没有证据表明您的示例实现了 IDisposable，但即使它们实现了，IDisposable 也不会提供“死亡事件”。所以这不是解决方案。

在这种情况下。您的本地“阅读器”变量因 NonDerivedCass 而死，因为它是该类的私有(private)变量。但是全局存储的 IConfigReader 实例仍然有效 在整个应用程序生命周期内 .

全局变量不是你的 friend 。坚持 SOLID 设计原则(见)。

这些备注的完整代码位于 https://github.com/marcusts/xamarin-forms-annoyances .相关解决方案见 AwaitAsyncAntipattern.sln 和 IocAntipattern.sln。

GitHub 站点还提供了有关此主题的更详细讨论的链接。