.netcore入门26：.net core源码分析之依赖注入

最新推荐文章于 2023-06-24 14:23:12 发布
最新推荐文章于 2023-06-24 14:23:12 发布
阅读量1.6k 收藏 5
点赞数 2
文章标签： .netcore java 前端
原文链接：https://blog.csdn.net/u010476739/article/details/105999059
版权

环境：

  • window10
  • .netcore 3.1
  • vs2019 16.5.1

一、依赖注入说明

依赖注入的概念这里就不说了，随便百度一大堆。在aspnetcore框架中，依赖注入是一个很基础的东西，所以我们必须要很熟悉才行。但现在我们要讲的依赖注入不在aspnetcore框架中，而是在.netcore中，因为依赖注入相关的代码都是在包：Microsoft.Extensions.DependencyInjection和包：Microsoft.Extensions.DependencyInjection.Abstractions中的，aspnetcore框架只不过做了集成和一点扩展。

二、.netcore框架中的依赖注入特点

市面上有很多依赖注入框架（比如：spring、autofac、tinyioc等），他们都有共同的目的（即：解耦），但他们又都有自己的特点。.netcore中的依赖注入框架的特点是：简单轻量、仅支持构造函数注入

2.1 简单轻量

在.netcore控制台工程中，你只需要安装nuget包Microsoft.Extensions.DependencyInjection即可使用依赖注入，而这个包又仅依赖于包Microsoft.Extensions.DependencyInjection.Abstractions，这两个包的代码量非常少，所以比较轻量，看下图：

请添加图片描述

2.2 仅支持构造函数注入

不像其他的框架（比如：spring、autofac）支持字段、属性等多种方式注入，.netcore的依赖注入框架仅支持构造函数注入，我认为：这种注入方式虽然单一，但它能提高我们代码的可读性。
看下面的示例，当我们需要容器内的什么服务时，直接在构造函数中声明即可：

请添加图片描述

三、服务的生命周期

在说服务的生命周期之前先来探讨一个问题：当我们向依赖容器请求一个服务实例的时候，容器是新创建一个返回给我们？还是使用上次创建的实例返回给我们？
答：容器需要兼容这几种情况，不能只考虑单一的情况。
所以，依赖容器就有了服务生命周期的概念，即：在向容器中注册服务的时候，我们就应该声明这个服务的生命周期，这样当我们向容器请求服务实例的时候，容器就可以根据服务注册时指定的生命周期采取不同的策略了。

依赖容器中的服务有三类生命周期：

  • Singleton（容器内单例）
    全容器内唯一，即：无论你何时向容器中请求这个服务实例，容器返回的都是同一个。
  • Scoped（范围内单例）
    范围内唯一。首先说下什么是范围：比如一次http请求，定时任务的一次调用执行等等。范围内唯一就是说在这个范围内，我们向容器请求服务实例，容器返回的总是同一个。不同的范围可以有不同的服务实例。
  • Transient（瞬时，非单例）
    Transient是瞬时的，即：当我们任何时候向依赖容器请求服务实例的时候，容器都会新创建一个返回给我们。

依赖服务容器生命周期的实现原理：

  • 我们可以根据一个依赖容器创建一个新的依赖容器（var scopedProvider = provider.CreateScope().ServiceProvider;），这样就可以由一个依赖容器衍生出很多依赖容器，但是只能有一个根容器（也就是使用ServiceCollection创建的依赖容器），其他的容器都是平级的，它们的关系如下图所示：
    请添加图片描述
    从上图我们应该能猜到服务生命周期的实现原理了，简单来说：

当我们向容器请求一个Singleton服务的时候，依赖容器从根容器中查找有没有已经创建好的实例，如果没有的话就新创建一个实例返回给我们并同时保存到根容器中。
当我们向容器中请求一个Scoped服务的时候，依赖容器查找自己有没有已经创建好的实例，如果没有的话就新创建一个实例返回给我们并同时自己保存一份。
当我们向容器请求一个Transient服务的时候，依赖容器直接新创建一个实例返回给我们（不做任何缓存）。
讲到这里，我们来思考1个问题：能不能从根容器中解析出Scoped类型的服务？

认为可以，此时根容器类似于其他的容器，它在自己内部缓存Scoped服务的实例。
认为不可以，此时根容器只能缓存Singleton服务实例，而Scoped服务只能由非根容器缓存，这也间接导致了Singleton服务不能依赖Scoped服务。
上面说的两种情况都有道理，下面的更严格一些，但.netcore的依赖注入框架默认是第一种情况，即：认为可以。我们可以在Build的时候改变这个默认：

static void Main(string[] args)
{
   var services = new ServiceCollection();
   services.AddScoped<Person>();
   var provider = services.BuildServiceProvider(new ServiceProviderOptions()
   {
       ValidateOnBuild = true,
       ValidateScopes = true
   });
}

上面的ValidateScopes表示的就是是否验证Scoped服务必须从非根容器中解析出来，默认是false，这里我们将它改为true。ValidateOnBuild表示我们是否在容器Build的时候就进行验证还是解析服务实例的时候再验证？默认是false，这里我们也设置为true，一旦设置为true后，容器在Build的时候就会检查是否有Singleton服务依赖了Scoped服务，如果有的话就直接报异常（因为Singleton服务依赖Scoped服务必然要引发根容器解析Scoped服务实例，除非你一直不向容器请求这个Singleton服务实例）。

在Build时验证失败的案例：
在Build服务容器的时候检查Singleton服务不能依赖Scoped服务：

请添加图片描述

在解析服务实例时验证失败的案例：
在解析Singleton服务实例的时候检查是否依赖到了Scoped服务：

请添加图片描述

在解析Scoped服务实例时检查是否是从根容器中解析的：

请添加图片描述

依赖注入的正确使用方式：
我们应尽可能的避免从根容器中解析Scoped服务，即遵循严格模式（ValidateScopes=true），代码示例如下：

namespace ConsoleApp7
{
    public class Teacher { }
    public class Book { }
    public class Stucent
    {
        public readonly Teacher teacher;
        public readonly Book book;
        public Stucent(Teacher teacher, Book book)
        {
            this.teacher = teacher;
            this.book = book;
        }
    }
    class Program
    {
        public static void Main(string[] args)
        {
            var services = new ServiceCollection();
            services.AddSingleton<Teacher>();
            services.AddSingleton<Book>();
            services.AddScoped<Stucent>();

            var provider = services.BuildServiceProvider(new ServiceProviderOptions()
            {
                ValidateScopes = true,
                ValidateOnBuild = true
            });
            var teacher = provider.GetService<Teacher>();
            var book = provider.GetService<Book>();

            var scopedProvider = provider.CreateScope().ServiceProvider;
            var student = scopedProvider.GetService<Stucent>();

            Console.WriteLine($"student.teacher==teacher=>{student.teacher == teacher}\r\nstudent.book==book=>{student.book == book}");

            Console.WriteLine("ok");
            Console.ReadLine();
        }
    }
}

运行效果如下：

请添加图片描述

四、循环依赖问题

这里我们思考一个问题，如果我们向容器中注册的服务存在循环依赖，那么当我们请求容器解析的时候容器会怎么办？
比如我们定义了三个服务：Teacher、Book、Student，然而它们相互依赖如下：

请添加图片描述

那么当我们请求服务实例的时候，容器肯定解析不了，直接给我们报个异常！ 看下面的代码：

namespace ConsoleApp7
{
   public class Teacher
   {
       public Teacher(Book book) { }
   }
   public class Stucent
   {
       public Stucent(Teacher teacher) { }
   }
   public class Book
   {
       public Book(Stucent stucent) { }
   }
   class Program
   {
       public static void Main(string[] args)
       {
           var services = new ServiceCollection();
           services.AddSingleton<Teacher>();
           services.AddSingleton<Stucent>();
           services.AddSingleton<Book>();

           var provider = services.BuildServiceProvider(new ServiceProviderOptions()
           {
               ValidateScopes = true
           });
           provider.GetService<Teacher>();
           Console.WriteLine("ok");
           Console.ReadLine();
       }
   }
}

运行报异常：

请添加图片描述

异常的原因很明显，产生了循环依赖。

正因为我们注册的服务可能存在循环依赖的问题，所以容器在初次解析某个服务实例时都会对这个服务的依赖链进行检查和判断，以防止再实例化过程中出现死循环的问题。
看下面的图所示，依赖关系虽然复杂，但是没有产生循环依赖：

请添加图片描述

再看下面的图所示，依赖关系虽然简单，但是却产生了循环依赖：

请添加图片描述

五、依赖容器对象

从上面的分析中我们知道了依赖容器有根容器和非根容器之说，那么根容器是哪个类表示的？非根容器又是哪个类表示的？他们是同一个类吗？
答：按照正常的理解，它们既然都是依赖容器，应该是同一个类。但事实上他们是不同的类：根容器使用类ServiceProvider（public sealed class ServiceProvider），非根容器使用类ServiceProviderEngineScope（internal class ServiceProviderEngineScope），他们都实现了IServiceProvider接口。
我们知道将服务注入到容器后，我们就可以在需要的时候向容器请求服务实例了，但是我们能不能向容器请求容器自身呢？看下面的代码：

请添加图片描述

看上面的代码，Student类根本不需要在构造函数中声明具体的服务依赖，它只需要引用依赖容器本身就行了，至于其他的服务，随时需要随时向容器请求就行了。首先，这种方式很灵活，其次，我们尽量不要使用这种方式！！！
下面我们结合provider.Get()和provider.CreateScope().ServiceProvider来看一下根容器和非根容器的区别：

请添加图片描述

IServiceCollection和IServiceProvider的关系：

请添加图片描述

先来探讨根容器的具体实现：
ServiceProvider：这个类是sealed的，所有向它发起服务解析请求的都会被转接到其内部的IServiceProviderEngine上。IServiceProviderEngine是事实上的服务提供者，在构建ServiceProvider的时候默认创建DynamicServiceProviderEngine对象。涉及到的一些其他的IServiceProviderEngine如下：

请添加图片描述

上图中涉及到的类全部是internal的，其中RuntimeServiceProviderEngine、ILEmitServiceProviderEngine和ExpressionsServiceProviderEngine在此次分析中并未涉及。

六、走进源码

源码中涉及到的接口和职责如下：

6.1 IServiceProvider

表示服务提供容器，即实现了这个接口的对象应该具有向用户提供服务实例的能力。不过这个接口是.netcore的基础库里面的，并不是包：Microsoft.Extensions.DependencyInjection或包：Microsoft.Extensions.DependencyInjection.Abstractions中的。在.netcore的基础库中仅定义了一个GetService方法，但在包：Microsoft.Extensions.DependencyInjection.Abstractions中对这个接口做了扩展，代码如下：

namespace System
{
    public interface IServiceProvider
    {
        object GetService(Type serviceType);
    }
}

namespace Microsoft.Extensions.DependencyInjection
{
	public static class ServiceProviderServiceExtensions
	{
		public static T GetService<T>(this IServiceProvider provider)
		{
			...
		}
		public static object GetRequiredService(this IServiceProvider provider, Type serviceType)
		{
			...
		}
		public static T GetRequiredService<T>(this IServiceProvider provider)
		{
			...
		}
		public static IEnumerable<T> GetServices<T>(this IServiceProvider provider)
		{
			...
		}
		public static IEnumerable<object> GetServices(this IServiceProvider provider, Type serviceType)
		{
			...
		}
		public static IServiceScope CreateScope(this IServiceProvider provider)
		{
			return provider.GetRequiredService<IServiceScopeFactory>().CreateScope();
		}
	}
}

从上面的代码可以看到，IServiceProvider的主要能力就是提供服务实例（GetService…），但它作为和.netcore程序员交互的接口必须具有创建新范围的能力，所以最后一段代码扩展了CreateScope方法。

6.2 IServiceScope

表示一个服务范围，在这个范围内部存在一个IServiceProvider（服务提供容器）可以对外提供解析服务实例。它被定义在包：Microsoft.Extensions.DependencyInjection.Abstractions中。代码如下：

namespace Microsoft.Extensions.DependencyInjection
{
	public interface IServiceScope : IDisposable
	{
		IServiceProvider ServiceProvider { get; }
	}
}

6.3 IServiceScopeFactory

表示服务范围创建工厂，具有创建一个新范围的能力。它被定义在包：Microsoft.Extensions.DependencyInjection.Abstractions中。代码如下：

namespace Microsoft.Extensions.DependencyInjection
{
	public interface IServiceScopeFactory
	{
		IServiceScope CreateScope();
	}
}

6.4 IServiceProviderEngine

表示服务提供引擎，这个和IServiceProvider不同，IServiceProvider提供服务实例的能力最终是由IServiceProviderEngine提供的。它被定义在包：Microsoft.Extensions.DependencyInjection中，代码如下：

namespace Microsoft.Extensions.DependencyInjection.ServiceLookup
{
	internal interface IServiceProviderEngine : IServiceProvider, IDisposable, IAsyncDisposable
	{
		IServiceScope RootScope { get; }
		void ValidateService(ServiceDescriptor descriptor);
	}
}

6.5 ServiceProvider

这是一个public sealed类，实现了IServiceProvider接口，表示根容器，最初我们使用ServiceCollection进行Build的时候就是生成它的实例。它内部封装一个_engine（IServiceProviderEngine）对象，所有
解析服务实例的请求都转移到这个_engine对象上。注意：它只是表示根容器，子容器并不是用它来表示的。它被定义在包：Microsoft.Extensions.DependencyInjection中，代码如下：

namespace Microsoft.Extensions.DependencyInjection
{
	public sealed class ServiceProvider : IServiceProvider, IDisposable, IServiceProviderEngineCallback, IAsyncDisposable
	{
		internal ServiceProvider(IEnumerable<ServiceDescriptor> serviceDescriptors, ServiceProviderOptions options)
		{
			...
			this._engine = new DynamicServiceProviderEngine(serviceDescriptors, callback);
		}

		public object GetService(Type serviceType)
		{
			return this._engine.GetService(serviceType);
		}
		private readonly IServiceProviderEngine _engine;
		...
	}
}

6.6 ServiceProviderEngineScope

这是一个internal类，同时实现了IServiceScope和IServiceProvider，也就是说它既可以当做范围也可以当做服务容器。注意：所有的子容器都是由它来表示的。它的属性ServiceProvider（IServiceProvider）指向自己，恰好说明了自身既可以是范围也可以是服务容器。它还有一个属性Engine（ServiceProviderEngine），指向了服务容器引擎，这里注意：整个依赖注入框架就只有一个服务提供引擎（在由ServiceCollection进行创建根容器ServiceProvider的时候创建，一般是：DynamicServiceProviderEngine）。它被定义在包：Microsoft.Extensions.DependencyInjection中，代码如下：

namespace Microsoft.Extensions.DependencyInjection.ServiceLookup
{
	internal class ServiceProviderEngineScope : IServiceScope, IDisposable, IServiceProvider, IAsyncDisposable
	{
		public ServiceProviderEngineScope(ServiceProviderEngine engine)
		{
			this.Engine = engine;
		}
		public ServiceProviderEngine Engine { get; }
		public object GetService(Type serviceType)
		{
			if (this._disposed)
			{
				ThrowHelper.ThrowObjectDisposedException();
			}
			return this.Engine.GetService(serviceType, this);
		}
		public IServiceProvider ServiceProvider
		{
			get
			{
				return this;
			}
		}
		//...
	}
}

6.7 ServiceProviderEngine

这是一个internal abstract 类，它同时实现了IServiceProviderEngine、IServiceProvider和IServiceScopeFactory接口，说明它既可以是服务提供引擎，也可以是服务容器，也可以从它创建新的范围，不过它主要是一个服务提供引擎。上面说的 “一个依赖注入框架就只有一个服务提供引擎” ，说的就是它。也只有在它的内部具体实现了IServiceScopeFactory的CreateScope方法。它的内部还封装着Root和RootScope属性（Root=RootScope，ServiceProviderEngineScope），这两个属性引用的同一个对象：根容器范围（ServiceProviderEngineScope），这个根容器范围是在创建ServiceProviderEngine的时候一起创建的。它的子类DynamicServiceProviderEngine应该是我们使用的使用的具体对象了，涉及代码如下：

namespace Microsoft.Extensions.DependencyInjection.ServiceLookup
{
	internal abstract class ServiceProviderEngine : IServiceProviderEngine, IServiceProvider, IDisposable, IAsyncDisposable, IServiceScopeFactory
	{
		protected ServiceProviderEngine(IEnumerable<ServiceDescriptor> serviceDescriptors, IServiceProviderEngineCallback callback)
		{
		    //...
			this.Root = new ServiceProviderEngineScope(this);
		}
		public ServiceProviderEngineScope Root { get; }
		public IServiceScope RootScope
		{
			get
			{
				return this.Root;
			}
		}
		public object GetService(Type serviceType)
		{
			return this.GetService(serviceType, this.Root);
		}
		internal object GetService(Type serviceType, ServiceProviderEngineScope serviceProviderEngineScope)
		{
			//...
		}
		public IServiceScope CreateScope()
		{
			if (this._disposed)
			{
				ThrowHelper.ThrowObjectDisposedException();
			}
			return new ServiceProviderEngineScope(this);
		}
		//...
	}
}
namespace Microsoft.Extensions.DependencyInjection.ServiceLookup
{
	internal abstract class CompiledServiceProviderEngine : ServiceProviderEngine
	{
		public CompiledServiceProviderEngine(IEnumerable<ServiceDescriptor> serviceDescriptors, IServiceProviderEngineCallback callback) : base(serviceDescriptors, callback)
		{
			//...
		}
		//...
	}
}
namespace Microsoft.Extensions.DependencyInjection.ServiceLookup
{
	internal class DynamicServiceProviderEngine : CompiledServiceProviderEngine
	{
		public DynamicServiceProviderEngine(IEnumerable<ServiceDescriptor> serviceDescriptors, IServiceProviderEngineCallback callback) : base(serviceDescriptors, callback)
		{
		}
		//...
	}
}

6.8 相关接口和类总结

首先看下面的图：

请添加图片描述

上图中显示了依赖注入涉及到的主要接口和类的相互之间关系。下面来看一下，服务容器、服务提供引擎和服务范围之间的关系：
请添加图片描述

6.9 重点问题

依赖注入框架就只有一个服务提供引擎（一般是：DynamicServiceProviderEngine），这是怎么做到的？
首先，由ServiceCollection创建ServiceProvider的时候就创建了服务提供引擎，并将它储存在了ServiceProvider中，之后由ServiceProvider创建新的范围的时候（或者是由子范围创建新范围的时候），其实就是调用服务提供引擎的CreateScope方法，而服务提供引擎的CreateScope方法执行的时候将自身传递给了新创建的范围（new ServiceProviderEngineScope(this)），所以整个依赖框架就只有一个服务提供引擎。

七、注入泛型服务

依赖框架在解析泛型服务的时候相当灵活，我们先定义下面的泛型类：

public class Teacher
{
    public Teacher()
    {
        Console.WriteLine("Teacher ctor...");
    }
}
public class Book
{
    public Book()
    {
        Console.WriteLine("Book ctor...");
    }
}
public class Student<T>
{
    public Student(T t)
    {
        Console.WriteLine("Student ctor...");
    }
}

依赖注入中的简单泛型：
我们可以在依赖注入的时候指定泛型的具体类型，看下面的代码：

class Program
{
    public static void Main(string[] args)
    {
        var services = new ServiceCollection();
        services.AddSingleton<Teacher>();
        services.AddSingleton<Book>();
        services.AddSingleton<Student<Book>>();
        services.AddSingleton<Student<Teacher>>();
        var provider = services.BuildServiceProvider();

        var serv = provider.GetService<Student<Book>>();
        var serv2 = provider.GetService<Student<Teacher>>();
        Console.WriteLine("ok");
        Console.ReadLine();
    }
}

运行效果：

请添加图片描述
这个泛型应用起来还是比较简单的，但是不够灵活。比如说我只想将Student注入进去，至于具体的泛型类型我想解析的时候再指定，那怎么办呢？看下面的代码：

class Program
 {
     public static void Main(string[] args)
     {
         var services = new ServiceCollection();
         services.AddSingleton<Teacher>();
         services.AddSingleton<Book>();
         services.AddSingleton(typeof(Student<>));
         var provider = services.BuildServiceProvider();

         var serv = provider.GetService<Student<Book>>();
         var serv2 = provider.GetService<Student<Teacher>>();
         Console.WriteLine("ok");
         Console.ReadLine();
     }
 }

运行效果如下：

请添加图片描述
这样应用起来就相当灵活了。

原文链接：https://blog.csdn.net/u010476739/article/details/105999059

Ycj_3355
关注
  • 2
    点赞
  • 踩
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
NETCore.MailKit:.NET Core EmailKit扩展
05-15
NETCore.MailKit 用于asp.net核心的MailKit扩展 用nuget安装 Install-Package NETCore.MailKit -Version 2.0.3 使用.NET CLI安装 dotnet add package NETCore.MailKit --version 2.0.3 如何使用 在启动时添加MailKit，例如 public void ConfigureServices ( IServiceCollection services ) { // Add framework services. services . AddMvc (); // Add MailKit services . AddMailKit ( optionBuilder => { optionBuilder . U
Udemy.NetCore.RCN.API:.Net Core中的Eb光标Api
04-12
UDEMY.RCN.API ASP.NET CORE中WBE API的研究 ASP.NET CORE 2.2 + EF CORE 2.2+ GITHUB + AZUR课程
Xunit.Gherkin.Quick：.NET Core中的BDD-使用Xunit和Gherkin（与.NET Core和.NET兼容）
02-05
努吉特： 建立状态： Xunit.Gherkin.Quick Xunit.Gherkin.Quick是一个轻量级的跨平台BDD测试框架（目标是.NET Standard，可以在.NET和.NET Core测试项目中使用）。 它解析Gherkin语言并执行与场景相对应的Xunit测试。 项目发起人 通过赞助该项目在这里展示您公司的徽标！ 注意：如果您想成为赞助商，可以在此页面上找到赞助商链接，并以提供您的徽标和详细信息。 感谢您的考虑，并享受框架！ 入门 我们将快速设置项目，编写我们的第一个BDD测试，然后运行它。 Xunit测试项目 创建一个新的或打开的现有Xunit测试项目。 Xu
C# (.NET Core 6.0) DI依赖注入 示例
08-04
较为框架式的演示了DI服务依赖注入 适用于熟悉C#中的继承,基本的Core命令使用等. 该示例演示了以服务器集群为背景的各种业务的依赖注入. 示例来自于B站杨中科老师的.NET Core(6.0)教学.
X.Web.Sitemap:.NET和.NET Core的简单站点地图生成器
05-16
X.Web.Sitemap 适用于.NET和.NET Core的简单站点地图生成器，您可以从nuget.org上下载它，网址为 用法示例 以下是不可测试方式的基本用法示例 class Program { static void Main ( string [] args ) { var sitemap = new Sitemap (); sitemap . Add ( new Url { ChangeFrequency = ChangeFrequency . Daily , Location = " http://www.example.com " ,
详解asp.net core 依赖注入
12-17
前言 　　好久没有写微博了，因为前段时间由于家庭原因决定从工作了3年多的北京转移到上海去。依赖注入在学习net core的时候也有写过类似的东西，只是实践的较少，结果来到上海新公司系统框架涉及到了这块知识点，所以在了解完自己的项目之后决定做一些相关的总结。接下来就让我们先来了解hewi依赖注入。 什么是依赖注入 　　依赖注入，全称是“依赖注入到容器”， 容器（IOC容器）是一个设计模式，它也是个对象，你把某个类（不管有多少依赖关系）放入这个容器中，可以“解析”出这个类的实例。所以依赖注入就是把有依赖关系的类放入容器（IOC容器）中，然后解析出这个类的实例。划重点：依赖注入是为了实现控制反转的一
C# .NetCore知识点
qq_43420566的博客
02-28 6631
1、.netCore的执行过程 2、如何在controller中注入service? 在Config Services方法中配置这个service 在Controller的构造函数中 添加这个依赖注入 3、.netCore比.net更具优势的地方是什么？ 跨平台，可以运行在 Windows 、Linux 和 MAC 系统上 对框架本身安装没有依赖，所有依赖都和程序本身在一起 .netCore处理请求的效率更高，进而可以处理更多的请求 具有更多的安装配置方法 4、.netCore主要的特性有哪些？ 依赖注入
什么是.NET Core以及.NET Core能做什么?
最新发布
ZyrJavascrip的博客
06-24 1385
NET Core支持微服务体系结构，它允许跨平台服务与.NET Core一起工作，包括使用.NET Framework、Java、Ruby或其他开发的服务。第一个版本的.NET Core 1.0是在2016年发布的，功能有限。与.NET Framework和.NET Core 2.2及以前的版本相比，.NET Core 3.0的速度很快。与其他软件框架不同，.NET Core是最通用的框架，可用于构建各种软件，包括Web应用程序、移动应用程序、桌面应用程序、云服务、微服务、API、游戏和物联网应用程序。
NetCore 的几个重要的技术点
weixin_46681279的博客
06-10 3120
Net Core 重要的技术点 1、中间件概念 Asp.Net Core作为控制台应用程序启动，在Program的Main方法是入口，通过调用CreateWebHostBuilder或者（CreateDefaultBuilder）创建WebHost的，WebHost会利用WebHostBuilder提供的服务器和中间件构建一个请求处理管道；这就是ASP.NET Core框架的核心（一个服务器和若干中间件构成的管道）。 Host.CreateDefaultBuilder(args)
.NET Core学习笔记
分享的越多，得到的越多。 记录的越多，忘记的越少。
08-20 2752
表示段落缩进.NET是.NET Framework、.NETCore、Xamarin/Mono的统称。.NET FrameWork框架只能开发Windows平台的应用程序，也就是说用.NET FrameWork框架做出来的程序只能运行在Windows系统下。.NET Core框架是免费、开源、跨平台的，可以运行在Linux、Macos、Windows平台下。.........
C# .NetCore学习总结
qq_38192821的博客
05-10 892
什么是.NetCore？Hosting，Kestrel，中间件。
NetCore框架详解 -------四、.NetCore框架对依赖注入原则 的技术实现和运行原理
zhoujian_911的专栏
05-05 1822
前三章主要从理论角度讲述了依赖注入原则及所衍生实现技术和手段产生的原因、发展和当前所处状况。大部分开发人为前三章对自己的技术水平的提高设有立竿见影的直接作用，但的我在里还是要说一下，前三章不但可以使开发者对更加容易的理解.NetCore框架，也是让开发者知道微软为什么会在已经有了一个成熟、使用范围广的.NetFramework框架时还会推出一个新的.NetCore框架历史和技术的重要因素。再者前三章理论性的知识在10年后对开发者或许还有指导作用，以下关于技术方面的具体实现或许因为对当前技术有着重要的指导性，
为什么选择.NETCore
m0_73494896的博客
08-31 454
如果您在.NET中发现了一个错误，最好找到一个解决方法，而不是等待更新（这也是.NETCore开源带来的好处，您不需要完全依赖微软支持才能解决问题，这对于大型企业更是有利，可以利用技术资源来对.NETCore进行本企业定制化，成为.NETCore的分支来运行）。微软并没有移植所有的.NET Framework，对于ASP.NET客户来说，ASP.NET团队是.NET Core的驱动因素。.NET Framework支持旧版本的ASP.NET项目，而且这个约束限制了ASP.NET的发展。...
NetCore配置详解(1)
世界既不黑也不白，而是一道精致的灰。
08-24 1720
提供一个实现了 IConfigurationProvider 接口的配置提供类，它需要提供配置的读取以及更新等操作提供一个 IConfigurationSource 接口实现类，它负责创建 IConfigurationProvider。创建一个 IConfigurationBuilder 配置建造者对象，然后将 IConfigurationSource 添加进配置构造者中，这里我们一般都采用 IConfigurationBuilder 的拓展方法来实现。
.netcore基础知识（一）
xuhss_com的博客
02-12 1234
Python微信订餐小程序课程视频 https://edu.csdn.net/course/detail/36074 Python实战量化交易理财系统 https://edu.csdn.net/course/detail/35475 先来说说web服务器 先来一张图 一个典型的进程外托管模型 我们先看kestrel这一部分 我们在它前面放了一个方向代理服务器nginx 对http请求做预处理 kestrel本身是可以直接用作web服务器的 但是其功能较弱 只有基础功能 说白了就是一个弱化版的IIS 所
.Net Core 依赖注入
睡在上铺的猴
08-04 4186
为什么要使用依赖注入框架 .Net Core DI 核心类 三种生命周期 服务注册 单例注册 作用域注册 瞬时注册 直接注入实例 工厂模式注册 注册不同实例 尝试注册 移除和替换注册 注册泛型模板 使用依赖注入注意点 实现 IDisposable 接口类型的释放 Autofac 基于名称的注入 属性注入 子容器 基于动态代理的 AOP
ASP.NET Core — 依赖注入
weixin_37648525的博客
11-19 4579
NET Core 框架下默认提供250个以上的的服务，包括ASP.NET Core MVC、EF Core 等等，当然这些服务很多不会默认就注入到容器中，我们在新建一个项目的时候，不同项目框架的模板会帮我们默认配置好一些最基本的必须的服务，其他的服务我们可以根据自己的需要进行使用。这也是我们在日常开发中可以学习的方式，随着业务增长，需要依赖注入的服务也越来越多，我们可以根据业务模块，通过扩展方法讲相应模块的服务注入注册进行封装，命名为 Add{Services}，更加清晰明了地对我们的业务进行封装。
初识.Netcore(1)
weixin_61229532的博客
12-14 1398
.Netcore:微软中跨平台的软件开发平台 （1）.netcore中的Request使用： <1>:接受前台传值： get:Request.Query["name"] post:Request.Form["name"]; <2>获取ip地址: string ipaddress = HttpContext.Connection.RemoteIpAddress.ToString(); <3>请求方式get,post等: string RequestType.
[.net core]简介(转)
weixin_34190136的博客
12-18 260
  原文地址：https://docs.microsoft.com/zh-cn/dotnet/articles/core/ NET Core 是一个通用开发平台，由 Microsoft 和 GitHub 上的 .NET 社区共同维护。 它是跨平台的，支持 Windows、macOS 和 Linux，并且可用于设备、云和嵌入式/IoT 方案。 以下特征对 .NET Core 进行了最好的定义：...
netcore 编译 html,Asp.Net Core 源码编译过程
06-10
ASP.NET Core源码编译需要使用.NET Core SDK，因此首先需要安装.NET Core SDK。然后，可以按照以下步骤进行编译： 1. 下载ASP.NET Core源码 可以通过Git从GitHub上下载ASP.NET Core源码。运行以下命令： ``` git clone https://github.com/dotnet/aspnetcore.git ``` 2. 切换到所需的分支 ASP.NET Core有多个分支，可以选择需要编译的分支。例如，要编译3.1版本的代码，可以运行以下命令： ``` cd aspnetcore git checkout release/3.1 ``` 3. 运行build.cmd脚本 在ASP.NET Core源码根目录中，有一个名为`build.cmd`的脚本。运行该脚本，它将使用.NET Core SDK将ASP.NET Core源码编译为可执行文件。 ``` .\build.cmd ``` 4. 编译HTML文件 ASP.NET Core中的HTML文件可以使用Razor语法编写。编写Razor模板文件后，可以使用Razor命令行工具将其编译为C#代码。例如，要编译名为`Index.cshtml`的文件，可以运行以下命令： ``` dotnet razor compile Index.cshtml ``` 这将生成一个名为`Index.cshtml.cs`的文件，其中包含编译后的C#代码。 以上就是ASP.NET Core源码编译和HTML文件编译的过程。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值