“在.NET Core中，ASP.NET Core内置了依赖注入容器IServiceCollection和服务提供者IServiceProvider。对开发者来说，通过建立抽象，提取出接口或基类，再将该对象注册到依赖注入容器中。
在服务调用时，上层应用不再通过new的形式使用下层接口，而是在构造函数中，通过引入依赖注入框架实例化的下层实现，并由该框架来统一管理对象的生命周期。
这就是依赖注入框架所采取的手段。”
4“听起来还是挺不错的，就是对开发者的操作习惯造成了一些影响。”木哥叹息道。
董哥点了点头，“对许多开发者来说，改变习惯如同断人财路。我也曾经见过很多开发者特别喜欢使用全局静态变量，仿佛不用静态变量就不会写代码了。事实上对专业开发者来说，出现的每一个静态变量都会让其产生很痛苦的感觉。
首先，全局静态变量由root根来进行管理的对象，除非应用程序退出，这些对象几乎不会释放。如果开发者再玩一些骚操作，例如用全局静态变量来存放集合，有时会成为gc的一场灾难片。
其次，全局静态变量就是单例对象，全局只会出现一次实例，并发访问时，很容易就会引发线程安全问题。线程安全问题看起来简单，实则是软件开发中最难处理的一类问题了。为了一劳永逸，有的开发者习惯于用lock语句来强制使之同步化，这又使得应用程序很难充分利用硬件性能带来的优势。
所以，开发者有时改变一些思维定势，例如尽量不要出现全局静态变量，如果一定要出现，也推荐使用依赖注入框架所提供的单例生命周期来管理，这样使得整个应用系统的生命周期管理都处于可控状态。当然，全局静态方法是允许存在的，类似于 public static string xxx这样的扩展方法，可以使开发者的代码变得非常优雅。
在我看来，定义接口，通过依赖注入框架注册对象，通过构造函数创建对象，看起来非常简单的三个步骤，却有可能使应用系统开发变得更加的高可控，仅就这么一个小小的变化，就已经显得.NET Core开发比传统.NET 开发更加的充满魅力和神奇。“
5董哥一时激动，讲了许多在木哥看来有点完全搞不懂的概念。这也使得小木突然间一脸懵逼，不知道该如何接下这个话题，半响之后，他才逐渐吐出一个问题：”董哥，你说的单例生命周期是啥意思？我在.NET Core开发中好像隐约看到过，但有点不太理解它的含义，你能跟我简单讲一下么。“
董哥也意识到自己突然间聊嗨了，兀自的笑了一笑，然后说：“
在.NET Core提供的依赖注入框架中，提供了三种不同的生命周期。
第一种就是SingleTon单例生命周期，这种模式有点像设计模式中的单例模式，通俗而言，就是在软件的整个生命周期只会出现唯一一次实例，并随着应用程序的结束而销毁。他有点像全局静态变量，只是整个过程都由依赖注入框架管理。许多全局变量都可以通过该生命周期所提供的服务层维护。
第二种就是Scoped生命周期，用中文翻译有点像作用域，这个作用域如何理解呢，我们都知道，http请求实际上是以为会话的形式进行的，每个会话往往会有IIS宿主开辟独立的线程来进行支持，那么这个作用域大概就像是给每个会话开辟的独立线程。在这个线程的生命周期内，开发者都能从依赖注入框架中，便捷的引入适当的服务层来提供业务支持。
第三种则是Transient生命周期，瞬时生命周期。一瞬间就过去了，说明时间很快。当然，如果用一句佛经来形容，那就是
一刹那者为一念，二十念为一瞬，二十瞬为一弹指，二十弹指为一罗预，二十罗预为一须臾，一日夜有三十须臾。
这个一瞬间，大概是0.36秒，实际上程序执行可能比这快很多。程序语言目前还无法跟佛经对应起来，我们只能把它理解为，一次方法调用过程为瞬时。一般是那种需要随用随取的对象，主要是相对于Scoped而言的，在控制台应用中使用非常广泛。
.NET Core提供的这三种生命周期，看起来很简单，但有时候也比较容易就踩坑了，这就需要我们平时注意自己的使用习惯了。“
6一晃围绕这个话题，他们已经聊了一个半小时，随着窗外夕阳的逐渐消逝，窗外初上的华灯也使两位大佬意识到时间不早了，于是，他们也离开了办公室。