官方例子很好地说明了，在一个web应用程序中应该如何分配组件注册的生命周期的选择问题：
现在应用程序具有一个全局单例日志记录服务，然后两个同时请求进入Web应用程序，每个请求都是一个逻辑的“工作单元”，每个请求都需要自己的订单处理服务，每个订单处理服务都需要将信息记录到日志服务中。在这种情况下，拥有包含单例记录服务的根生存期范围，并且每个请求都有一个子生命周期范围child scope，每个范围都有自己的订单处理服务：
当每个请求结束时，请求生存期范围结束，相应的订单处理器被释放（如果实现了IDisposable）。Log日志记录服务作为一个单例，在将来的请求中保持共享。
关于具体注册的时候可供选择的实例生命周期范围，默认情况下是使用的：InstancePerDependency 也就是瞬态，每次解析都是一个新的对象，SingleInstance 单例不多说，InstancePerLifetimeScope scope范围内共享实例，通过 BeginLifetimeScope 即可建立一个scope范围，InstancePerMatchingLifetimeScope 指定具体name的scope范围内实例对象共享，其中pre request scope就是利用这道理实现了每次请求一个独立的作用域，InstancePerRequest web应用单次请求组件单例，注意如果木有请求的环境下，解析组件会抛出异常，InstancePerOwned 基本用不到，Thread Scope 参照线程启动的时候构建InstancePerLifetimeScope类型的作用范围曲线救国就可以了
关于服务依赖导致各自依赖项长期存活问题，一般情况下，应用程序中，上层服务组件所需要依赖的下层服务的生命周期要小于等于上层服务的生命周期即可，这样就可以正确的表示依赖关系和隶属关系，但是得除开单例情况，因为它是贯穿了整个应用生命周期的存在。
关于组件对象的释放问题，一般的ioc容器包括autofac都已经实现了自动处理释放问题，根据不同的注册生命周期选择，则会自动释放，不需要开发者关系，对象残留的问题。如需要手动释放其他自定义非托管资源可以利用 OnRelease event来自定义处理逻辑，注意这会覆盖base逻辑，所以如果本身组件实现了idisposable就要先调用base.Diposable()方法
注册配置来源这里博主还是推荐代码注册，因为配置文件的管理也是挺麻烦的，除非需要再上线之后需要动态调整一下注册参数或者生命周期的选择等等，那就需要xml json等注册方式，一般情况不会自定注册源，且autofac module 的方法很好划分了大量组件分类注册的问题。
各种应用程序集成这里直接复制粘贴官方对每个应用的demo代码即可，思路都是替换既有系统的默认的注册依赖组价，基本上已经足够我们的使用，到时开发的时候直接参考sample即可
这里官方给出了最佳实践的一些开发方式或者注意点： 我这里就不翻译，相信大家都看得懂
本来这篇水文在早些时候都应该要完成的，拖拖踏踏到现在，连广州都已经也到了冬天了，好冷......，还好有防寒服加持，至此，差不多主要博主想研究的框架都差不多了，至于说net core相关的也在偶尔持续关于 github issues 的动态，毕竟官方给了road map ，跪着也要实现不是嘛！接下来，博主就要基于实际应用开发集成各式组件，构建属于自己的单体应用架构，毕竟走向分布式的前提是，单体架构不够使用的情况下，当然后面设计的时候会相对引入一些ddd的相关思想，但并非全部，因为要基于显示考虑问题才是嘛......未完待续！