Xamarin，Autofac，NavigationService和BeginLifetimeScope [英] Xamarin, Autofac, NavigationService and BeginLifetimeScope
问题描述
在xamarin应用程序中，有关使用autofac的生命周期镜以及何时使用它们的初学者问题.
A beginner question on lifetimescopes with autofac and when to use them, in a xamarin app.
如本文所述( https://nblumhardt.com/2011/01/an-autofac-lifetime-primer/)由autofac文档(
As mentioned in this article (https://nblumhardt.com/2011/01/an-autofac-lifetime-primer/) which is referred to by the autofac documentation (http://docs.autofac.org/en/latest/lifetime/) they hammer a lot on not resolving from the root container but using seperate lifetimescopes and thinking in terms of units of work because autofac hold referenences to disposable objects even if they are not used anymore until the scope they were created on is disposed, and therefore there is the danger of memory leaks.
但是，在开发Xamarin应用程序并查找示例时，我没有找到这种用法的示例，也没有想到将IoC容器用作服务定位器anitpattern，何时使用? ( https://xamarinforms.wordpress.com/tag/dependency-injection/)
However when developing a Xamarin application and looking for examples, I find no examples of this usage, also with using an IoC container as a service locator anitpattern in mind, when whould this be used? (https://xamarinforms.wordpress.com/tag/dependency-injection/)
这些文章展示了一个最佳实践"示例，该示例在xamarin应用程序中设置导航并解析必要的视图模型，并将其设置为与页面的绑定上下文: https://developer.xamarin.com/guides/xamarin-表格/企业应用程序模式/导航/和
These articles show a 'best practice' example of setting up navigation in a xamarin app and resolving the necessary viewmodels and setting them as bindingcontext to pages: https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/navigation/ and https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/mvvm/#automatically_creating_a_view_model_with_a_view_model_locator Not sure if this is best practice or just the best way to do things in xamarin forms.
但是，现在当这些视图模型由autofac实例化并且其中一个模型依赖于可抛弃的类时，会发生什么?
However, now what happens when these viewmodels get instantiated by autofac and one of these models have dependencies on classes that are disposable?
当请求viewModel时，将解析一个与页面匹配的新实例，并将其放在导航堆栈中.因此，在浏览页面时，堆栈变得越来越大，autofac会保留对所有一次性对象的引用，并且在应用程序的生命周期中(所有内容都从主容器中解析出来，没有使用单独的作用域)可能会持续很长时间.这里有碰到内存问题的风险吗?如果仍然存在引用这些未使用对象的风险，何时将所有这些未使用对象收集为垃圾?可能我缺少对它的实际工作方式的理解或在用法上的错误，但请注意
When a viewModel is requested a new instance is resolved matched with a page and put on a navigation stack. So when navigating pages the stack grows bigger and bigger, autofac keeps references to all the disposable objects, and during the lifetime of the application (everything gets resolved from the main container, no seperate scopes are used) which could last a long time, is there a risk here of running into memory issues? When do all these unused objects get garbage collected if there is a risk they are still referenced? Probably I am missing some understanding of how this actually works or making a mistake in its usage but note how the InternalNavigateToAsync method from the https://developer.xamarin.com/guides/xamarin-forms/enterprise-application-patterns/navigation/ just keeps adding pages to the stack when navigating to another page..
PS.附带一提，这看起来不错(scope.Resolve):
PS. On a side note, this, which looks fine (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 以及其他一些地方..):
and this from (http://docs.autofac.org/en/latest/register/registration.html and some other places as well..):
using(var scope = container.BeginLifetimeScope())
{
var reader = container.Resolve<IConfigReader>();
}
在autofac文档中使用，我想这最后一个是错字了吗? (container.Resolve而不是scope.Reslove，它周围有一个useless(?)范围块，无论如何都从该范围块内的主容器中进行解析...
is used in the autofac documentation, I suppose this last one is a typo?? (container.Resolve instead of scope.Reslove with a useless(?) scope block around it resolving from the main container anyway within this scope block...
推荐答案
遗憾的是，AutoFac和其他所谓的"IOC"容器和/或框架倾向于夸大其作用.它们也不是很像IOC.
Regrettably, AutoFac and other so-called "IOC" Containers and/or frameworks tend to exaggerate what they can do. They are also not very IOC-like.
如果我创建此普通香草类:
If I create this plain-vanilla class:
public class NonDerivedClass
{
using (var scope = contaner.BeginLifetimeScope())
{
var reader = container.Resolve<IConfigReader>();
}
}
...然后实例化，使用并最终销毁NonDerivedClass，读者也将如何知道也销毁了它?根据C#，我的意思是使用什么机制?没有一个. 对象未引发任何事件 ，因为该对象超出范围并可以进行垃圾收集.
... and then I instantiate, use, and finally destroy NonDerivedClass, how would the reader know to be destroyed as well? And I do mean, according to C#, using what mechanism? There isn't one. No event is raised by an object as it goes out of scope and becomes eligible for garbage collection.
没有证据表明您的示例实现了IDisposable，但是即使这样做，IDisposable也不会提供死亡事件".所以这不是解决方案.
There is no evidence that your examples implement IDisposable, but even if they did, IDisposable does not provide a "death event". So that is not the solution.
在这种情况下.您的本地阅读器"变量与NonDerivedCass一起消失，因为它是该类的私有对象.但是，在整个应用程序生命周期中，IConfigReader的全局存储实例仍然有效 .
In this case. your local "reader" variable dies with the NonDerivedCass because it is private to that class. But the globally stored instance of the IConfigReader stays alive for the entire app lifespan.
全局变量不是您的朋友.坚持SOLID设计原则(参阅).
Global variables are not your friends. Stick to SOLID design principles (which see).
这些评论的完整代码位于 https://github.com/marcusts/xamarin -forms-annoyances .请参阅相关的解决方案是AwaitAsyncAntipattern.sln和IocAntipattern.sln.
The complete code for these remarks is at https://github.com/marcusts/xamarin-forms-annoyances. See relevant solutions are AwaitAsyncAntipattern.sln and IocAntipattern.sln.
GitHub网站还提供了指向该主题的更详细讨论的链接.
The GitHub site also provides links to a more detailed discussion on this topic.
这篇关于Xamarin，Autofac，NavigationService和BeginLifetimeScope的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
