重新理解:ASP.NET 异步编程

简介:

相关博文:

本来这篇博文想探讨下异步中的异常操作,但自己在做异步测试的时候,又对 ASP.NET 异步有了新的认识,可以说自己之前对异步的理解还是有些问题,先列一下这篇博文的三个解惑点:

  • async await 到底是什么鬼???
  • 异步操作中发生异常,该如何处理?
  • 异步操作中发生异常(有无 catch throw 情况),Application_Error 会不会捕获?

之前测试过异步中的同步(很多种情况),这次我们把测试代码写更复杂些(异步中再进行异步),代码如下:

[Route("")]
[HttpGet]
public async Task<string> Index()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId1:" + Thread.CurrentThread.ManagedThreadId);
    var result = await Test();
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId6:" + Thread.CurrentThread.ManagedThreadId);
    return result;
}

public static async Task<string> Test()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId2:" + Thread.CurrentThread.ManagedThreadId);
    using (var client = new HttpClient())
    {
        var response = await client.GetAsync("http://stackoverflow.com/questions/14996529/why-is-my-async-asp-net-web-api-controller-blocking-the-main-thread");
        await Test2();
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId5:" + Thread.CurrentThread.ManagedThreadId);
        return await response.Content.ReadAsStringAsync();
    }
}

public static async Task<string> Test2()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId3:" + Thread.CurrentThread.ManagedThreadId);
    using (var client = new HttpClient())
    {
        var response = await client.GetAsync("http://stackoverflow.com/questions/33408905/pgadminiii-bug-on-query-tool");
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId4:" + Thread.CurrentThread.ManagedThreadId);
        return await response.Content.ReadAsStringAsync();
    }
}

输出结果(执行四次):

Thread.CurrentThread.ManagedThreadId1:8
Thread.CurrentThread.ManagedThreadId2:8
Thread.CurrentThread.ManagedThreadId3:6
Thread.CurrentThread.ManagedThreadId4:6
Thread.CurrentThread.ManagedThreadId5:6
Thread.CurrentThread.ManagedThreadId6:6

Thread.CurrentThread.ManagedThreadId1:7
Thread.CurrentThread.ManagedThreadId2:7
Thread.CurrentThread.ManagedThreadId3:8
Thread.CurrentThread.ManagedThreadId4:7
Thread.CurrentThread.ManagedThreadId5:7
Thread.CurrentThread.ManagedThreadId6:7

Thread.CurrentThread.ManagedThreadId1:5
Thread.CurrentThread.ManagedThreadId2:5
Thread.CurrentThread.ManagedThreadId3:5
Thread.CurrentThread.ManagedThreadId4:6
Thread.CurrentThread.ManagedThreadId5:6
Thread.CurrentThread.ManagedThreadId6:6

Thread.CurrentThread.ManagedThreadId1:8
Thread.CurrentThread.ManagedThreadId2:8
Thread.CurrentThread.ManagedThreadId3:8
Thread.CurrentThread.ManagedThreadId4:8
Thread.CurrentThread.ManagedThreadId5:8
Thread.CurrentThread.ManagedThreadId6:8

这个测试方法,我执行了无数次,大致就是上面的四种情况,我当时看到输出结果,其实是很凌乱的,我也大家也一样,并心里有一些疑问:你这真是异步编程吗?为啥线程千奇百怪?并且最后那个还只有一个线程,这和同步有啥区别???

针对上面这个疑问,我想了很久,并对自己产生了一些质疑的声音:你每天都在写 async await 代码,你真的了解它吗???然后我又重新找到上面那篇 jesse liu 的博文,反复读了很多篇,最后终于有了一些“顿悟”,结合上面的测试代码,我大致画了一张示意图:

结合上面的图,我说一下自己的理解,在做测试的时候,HttpClient.GetAsync 尽量让它执行时间长些,比如请求的 URL 可以是 stackoverflow 或 github(原因你懂得!),因为有个时间差,这样我们可以更好的了解线程的执行情况,上面图中“线程1、线程1x、线程3x、线程4x”等等,这些并不是不同线程,也就是说线程1有可能等于线程1x或线程3x。。。从上面的输出结果就可以看出,用线程x来表示两个输出之间所经历的 await 次数,这就证明了一个疑惑:await 并不一定会创建和之前不一样的线程。

到底什么是异步???我个人觉得,async 异步是一个伪概念,await 等待才是精髓,一个线程可以响应多个请求,如果是同步编程,一个线程在处理某一个请求的时候阻塞了(比如上面测试代码中的 HttpClient.GetAsync 网络操作),那么这个线程就会一直等待它处理,在这个等待的过程中,那么其他请求就不能再使用这个线程,又因为 IIS 线程池中的线程数量有限,那么同步编程下,高并发将是一个头疼的问题,试想一下,如果线程池中的线程数量为 100 个,这 100 个线程在同时处理 100 个请求的时候,都悲催的阻塞掉了,这时候第 101 个请求将无法执行,那么并发量就是 100。

接上面,同样的处理过程,如果是异步编程,那将是什么情况呢?比如一个线程在处理某一个请求的时候,执行到 await 操作,那么这个线程将会释放回到线程池,然后进行等待,等待的过程中,原来的那个线程就可以处理其他请求或者这个请求的其他操作,注意等待并不是线程等待,而是操作等待,我原来就很不理解这个地方,如果是线程等待,就表示这个线程会一直等待它完成,那和同步编程就是一样的了,所以这种理解是错误的,你可以这样理解:await 等待的过程中,没有线程!!!

再接上面,等待操作完成之后,这时候就会从线程池中随机拿一个线程继续执行,拿到的这个线程有可能是 await 操作刚刚释放掉的,但也有可能是其他线程,上图中的 2-6 操作就是这样,一图胜千言:

了解了整个过程之后,你才会明白 async await 到底是什么鬼?以及它真正的用武之地是什么?简单总结几点内容:

  • async 异步网络处理作用最明显(HttpClient 请求或数据库连接):这个我们大家都很清楚,也很好理解,如果是其他操作,比如一个异步方法中你做了很多费时的计算,那这个异步将没什么效果,说白了和同步一样,而对于网络操作,我们一般不做处理,发起请求之后等待它完成就行,所以这时候执行到这的线程,可以释放并会到线程池中,网络操作执行完成之后,再从线程池中随机拿一个线程继续执行。
  • async 异步并不是真正意义上的“异步”:什么意思呢?你仔细看下上面测试的输出结果,会发现 ManagedThreadId1-6 是顺序输出的,而不是先输出 ManagedThreadId4 再输出 ManagedThreadId3,所以,异步和同步的执行过程是一样的,并且一个请求下,执行时间也是一样的,上面的异步测试其实某种意义上,是测试不出任何东西的(从测试结果就可以看出),异步并不能减少你的执行时间,而是增加你的请求执行数量,这个东西说白了,其实就是并发量。
  • async 异步的精髓是 await:这个之前已经提到了,准确来说,async 异步的精髓是 await 时的线程回收与完成之后的线程切换,这个操作最大的价值是,避免线程的浪费等待,充分利用线程的执行,有点类似于地主不能容忍奴隶闲着做无意义的事,而是希望他们 24 小时不停工作一样。

另外,在 ASP.NET 应用程序中,我们可以使用 Thread.CurrentThread 来访问当前的执行线程,我之前想做这样一个测试,让当前执行线程 Sleep 一段时间,看看其他线程会不会执行,但 Thread.CurrentThread 并没有 Sleep 方法,而必须这样访问 Thread.Sleep(int millisecondsTimeout),如果这样执行这段代码,那么当前线程将会 Sleep,但其他线程并不会在它 Sleep 的时候,而继续执行,为什么?因为 CPU 在同一时间段内只能执行一个线程。

了解了 async await 到底是什么鬼后,博文一开始剩下的两个有关异步操作中的异常问题,现在理解起来就非常容易了:

  • 异步操作中发生异常,该如何处理?:和同步一样处理,同步中报错,异步也一样报错,有人可能有这样的疑问,比如测试代码中的 Index Action,执行到 await Test 内部操作的时候,突然抛出异常了,然后就想当然的认为,既然是异步执行的 Test 方法,那 Index 应该不会影响吧?其实你执行之后就会发现,Index 页面还是会抛出异常的,所以异常和异步没半毛钱关系
  • 异步操作中发生异常(有无 catch throw 情况),Application_Error 会不会捕获?:无 catch,Application_Error 会捕获;有 catch 无 throw,Application_Error 不会捕获;有 catch 有 throw,Application_Error 会捕获。

如果我们想让某一个异步方法,在执行抛出异常的时候,而不影响其他异步方法,那我们就 catch 而不 throw,比如我们的测试代码:

[Route("")]
[HttpGet]
public async Task<string> Index()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId1:" + Thread.CurrentThread.ManagedThreadId);
    var result = await Test();
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId6:" + Thread.CurrentThread.ManagedThreadId);
    return result;
}

public static async Task<string> Test()
{
    try
    {
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId2:" + Thread.CurrentThread.ManagedThreadId);
        using (var client = new HttpClient())
        {
            var response = await client.GetAsync("http://stackoverflow.com/questions/33408905/pgadminiii-bug-on-query-tool");
            System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId3:" + Thread.CurrentThread.ManagedThreadId);
            throw new Exception("test exception");//这里出现了异常
            return await response.Content.ReadAsStringAsync();
        }
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine("异常信息:" + ex.Message);
        return "";
        //throw ex;
    }
}

这样的效果就是 Index 页面不会报错,并且也不会影响其他方法执行,现在发现当时疑惑这个问题的时候,还蛮白痴的,还是那句话,异常和异步没半毛钱关系,相同的问题,同步也是这样进行处理的。

博文内容有点多,如果你不愿花时间看,可以直接记住这段话:如果你的应用程序请求访问很少(并发很小),异步和同步将是一样的效果,异步化改造是毫无意义的,而如果你的应用程序请求访问很多(并发很大),那么效果显而易见,如果使用异步将会为你省掉几台服务器的钱,但代码异步化并不能使你的应用程序执行速度加快(指的是代码执行速度),垃圾代码还是垃圾代码,并不会有任何的改善,所以,写好“好的代码”很重要!!!相关博文:

本来这篇博文想探讨下异步中的异常操作,但自己在做异步测试的时候,又对 ASP.NET 异步有了新的认识,可以说自己之前对异步的理解还是有些问题,先列一下这篇博文的三个解惑点:

  • async await 到底是什么鬼???
  • 异步操作中发生异常,该如何处理?
  • 异步操作中发生异常(有无 catch throw 情况),Application_Error 会不会捕获?

之前测试过异步中的同步(很多种情况),这次我们把测试代码写更复杂些(异步中再进行异步),代码如下:

[Route("")]
[HttpGet]
public async Task<string> Index()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId1:" + Thread.CurrentThread.ManagedThreadId);
    var result = await Test();
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId6:" + Thread.CurrentThread.ManagedThreadId);
    return result;
}

public static async Task<string> Test()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId2:" + Thread.CurrentThread.ManagedThreadId);
    using (var client = new HttpClient())
    {
        var response = await client.GetAsync("http://stackoverflow.com/questions/14996529/why-is-my-async-asp-net-web-api-controller-blocking-the-main-thread");
        await Test2();
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId5:" + Thread.CurrentThread.ManagedThreadId);
        return await response.Content.ReadAsStringAsync();
    }
}

public static async Task<string> Test2()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId3:" + Thread.CurrentThread.ManagedThreadId);
    using (var client = new HttpClient())
    {
        var response = await client.GetAsync("http://stackoverflow.com/questions/33408905/pgadminiii-bug-on-query-tool");
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId4:" + Thread.CurrentThread.ManagedThreadId);
        return await response.Content.ReadAsStringAsync();
    }
}

输出结果(执行四次):

Thread.CurrentThread.ManagedThreadId1:8
Thread.CurrentThread.ManagedThreadId2:8
Thread.CurrentThread.ManagedThreadId3:6
Thread.CurrentThread.ManagedThreadId4:6
Thread.CurrentThread.ManagedThreadId5:6
Thread.CurrentThread.ManagedThreadId6:6

Thread.CurrentThread.ManagedThreadId1:7
Thread.CurrentThread.ManagedThreadId2:7
Thread.CurrentThread.ManagedThreadId3:8
Thread.CurrentThread.ManagedThreadId4:7
Thread.CurrentThread.ManagedThreadId5:7
Thread.CurrentThread.ManagedThreadId6:7

Thread.CurrentThread.ManagedThreadId1:5
Thread.CurrentThread.ManagedThreadId2:5
Thread.CurrentThread.ManagedThreadId3:5
Thread.CurrentThread.ManagedThreadId4:6
Thread.CurrentThread.ManagedThreadId5:6
Thread.CurrentThread.ManagedThreadId6:6

Thread.CurrentThread.ManagedThreadId1:8
Thread.CurrentThread.ManagedThreadId2:8
Thread.CurrentThread.ManagedThreadId3:8
Thread.CurrentThread.ManagedThreadId4:8
Thread.CurrentThread.ManagedThreadId5:8
Thread.CurrentThread.ManagedThreadId6:8

这个测试方法,我执行了无数次,大致就是上面的四种情况,我当时看到输出结果,其实是很凌乱的,我也大家也一样,并心里有一些疑问:你这真是异步编程吗?为啥线程千奇百怪?并且最后那个还只有一个线程,这和同步有啥区别???

针对上面这个疑问,我想了很久,并对自己产生了一些质疑的声音:你每天都在写 async await 代码,你真的了解它吗???然后我又重新找到上面那篇 jesse liu 的博文,反复读了很多篇,最后终于有了一些“顿悟”,结合上面的测试代码,我大致画了一张示意图:

结合上面的图,我说一下自己的理解,在做测试的时候,HttpClient.GetAsync 尽量让它执行时间长些,比如请求的 URL 可以是 stackoverflow 或 github(原因你懂得!),因为有个时间差,这样我们可以更好的了解线程的执行情况,上面图中“线程1、线程1x、线程3x、线程4x”等等,这些并不是不同线程,也就是说线程1有可能等于线程1x或线程3x。。。从上面的输出结果就可以看出,用线程x来表示两个输出之间所经历的 await 次数,这就证明了一个疑惑:await 并不一定会创建和之前不一样的线程。

到底什么是异步???我个人觉得,async 异步是一个伪概念,await 等待才是精髓,一个线程可以响应多个请求,如果是同步编程,一个线程在处理某一个请求的时候阻塞了(比如上面测试代码中的 HttpClient.GetAsync 网络操作),那么这个线程就会一直等待它处理,在这个等待的过程中,那么其他请求就不能再使用这个线程,又因为 IIS 线程池中的线程数量有限,那么同步编程下,高并发将是一个头疼的问题,试想一下,如果线程池中的线程数量为 100 个,这 100 个线程在同时处理 100 个请求的时候,都悲催的阻塞掉了,这时候第 101 个请求将无法执行,那么并发量就是 100。

接上面,同样的处理过程,如果是异步编程,那将是什么情况呢?比如一个线程在处理某一个请求的时候,执行到 await 操作,那么这个线程将会释放回到线程池,然后进行等待,等待的过程中,原来的那个线程就可以处理其他请求或者这个请求的其他操作,注意等待并不是线程等待,而是操作等待,我原来就很不理解这个地方,如果是线程等待,就表示这个线程会一直等待它完成,那和同步编程就是一样的了,所以这种理解是错误的,你可以这样理解:await 等待的过程中,没有线程!!!

再接上面,等待操作完成之后,这时候就会从线程池中随机拿一个线程继续执行,拿到的这个线程有可能是 await 操作刚刚释放掉的,但也有可能是其他线程,上图中的 2-6 操作就是这样,一图胜千言:

了解了整个过程之后,你才会明白 async await 到底是什么鬼?以及它真正的用武之地是什么?简单总结几点内容:

  • async 异步网络处理作用最明显(HttpClient 请求或数据库连接):这个我们大家都很清楚,也很好理解,如果是其他操作,比如一个异步方法中你做了很多费时的计算,那这个异步将没什么效果,说白了和同步一样,而对于网络操作,我们一般不做处理,发起请求之后等待它完成就行,所以这时候执行到这的线程,可以释放并会到线程池中,网络操作执行完成之后,再从线程池中随机拿一个线程继续执行。
  • async 异步并不是真正意义上的“异步”:什么意思呢?你仔细看下上面测试的输出结果,会发现 ManagedThreadId1-6 是顺序输出的,而不是先输出 ManagedThreadId4 再输出 ManagedThreadId3,所以,异步和同步的执行过程是一样的,并且一个请求下,执行时间也是一样的,上面的异步测试其实某种意义上,是测试不出任何东西的(从测试结果就可以看出),异步并不能减少你的执行时间,而是增加你的请求执行数量,这个东西说白了,其实就是并发量。
  • async 异步的精髓是 await:这个之前已经提到了,准确来说,async 异步的精髓是 await 时的线程回收与完成之后的线程切换,这个操作最大的价值是,避免线程的浪费等待,充分利用线程的执行,有点类似于地主不能容忍奴隶闲着做无意义的事,而是希望他们 24 小时不停工作一样。

另外,在 ASP.NET 应用程序中,我们可以使用 Thread.CurrentThread 来访问当前的执行线程,我之前想做这样一个测试,让当前执行线程 Sleep 一段时间,看看其他线程会不会执行,但 Thread.CurrentThread 并没有 Sleep 方法,而必须这样访问 Thread.Sleep(int millisecondsTimeout),如果这样执行这段代码,那么当前线程将会 Sleep,但其他线程并不会在它 Sleep 的时候,而继续执行,为什么?因为 CPU 在同一时间段内只能执行一个线程。

了解了 async await 到底是什么鬼后,博文一开始剩下的两个有关异步操作中的异常问题,现在理解起来就非常容易了:

  • 异步操作中发生异常,该如何处理?:和同步一样处理,同步中报错,异步也一样报错,有人可能有这样的疑问,比如测试代码中的 Index Action,执行到 await Test 内部操作的时候,突然抛出异常了,然后就想当然的认为,既然是异步执行的 Test 方法,那 Index 应该不会影响吧?其实你执行之后就会发现,Index 页面还是会抛出异常的,所以异常和异步没半毛钱关系
  • 异步操作中发生异常(有无 catch throw 情况),Application_Error 会不会捕获?:无 catch,Application_Error 会捕获;有 catch 无 throw,Application_Error 不会捕获;有 catch 有 throw,Application_Error 会捕获。

如果我们想让某一个异步方法,在执行抛出异常的时候,而不影响其他异步方法,那我们就 catch 而不 throw,比如我们的测试代码:

[Route("")]
[HttpGet]
public async Task<string> Index()
{
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId1:" + Thread.CurrentThread.ManagedThreadId);
    var result = await Test();
    System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId6:" + Thread.CurrentThread.ManagedThreadId);
    return result;
}

public static async Task<string> Test()
{
    try
    {
        System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId2:" + Thread.CurrentThread.ManagedThreadId);
        using (var client = new HttpClient())
        {
            var response = await client.GetAsync("http://stackoverflow.com/questions/33408905/pgadminiii-bug-on-query-tool");
            System.Diagnostics.Debug.WriteLine("Thread.CurrentThread.ManagedThreadId3:" + Thread.CurrentThread.ManagedThreadId);
            throw new Exception("test exception");//这里出现了异常
            return await response.Content.ReadAsStringAsync();
        }
    }
    catch (Exception ex)
    {
        System.Diagnostics.Debug.WriteLine("异常信息:" + ex.Message);
        return "";
        //throw ex;
    }
}

这样的效果就是 Index 页面不会报错,并且也不会影响其他方法执行,现在发现当时疑惑这个问题的时候,还蛮白痴的,还是那句话,异常和异步没半毛钱关系,相同的问题,同步也是这样进行处理的。

博文内容有点多,如果你不愿花时间看,可以直接记住这段话:如果你的应用程序请求访问很少(并发很小),异步和同步将是一样的效果,异步化改造是毫无意义的,而如果你的应用程序请求访问很多(并发很大),那么效果显而易见,如果使用异步将会为你省掉几台服务器的钱,但代码异步化并不能使你的应用程序执行速度加快(指的是代码执行速度),垃圾代码还是垃圾代码,并不会有任何的改善,所以,写好“好的代码”很重要!!!




本文转自田园里的蟋蟀博客园博客,原文链接:http://www.cnblogs.com/xishuai/p/asp-net-async-await-and-exception-handling.html,如需转载请自行联系原作者

相关文章
|
3月前
|
数据库 开发者
.NET 异步编程之谜:async/await 模式究竟隐藏着怎样的神奇力量?
【8月更文挑战第28天】在当今注重效率和响应性的软件开发领域,.NET 的 async/await 模式如同得力助手,简化异步代码编写,使代码更易理解和维护。通过后台执行耗时操作,如网络请求和数据库查询,避免阻塞主线程,显著提升系统响应性。此模式不仅适用于网络请求,还广泛应用于数据库操作和文件读写。合理使用 async/await 可大幅优化性能,但需注意避免过度使用、正确处理调用链及异常,以确保系统稳定性和高效性。深入探索 async/await,助您构建更出色的应用程序。
47 0
|
5月前
|
设计模式 存储 编译器
【.NET Core】异步编程模式
【.NET Core】异步编程模式
41 2
|
5月前
|
SQL 设计模式 开发框架
.NET异步有多少种实现方式?(异步编程提高系统性能、改善用户体验)
想要知道.NET异步有多少种实现方式,首先我们要知道.NET提供的执行异步操作的三种模式,然后再去了解.NET异步实现的四种方式。
|
5月前
|
开发框架 .NET 对象存储
【.NET Core】深入理解异步编程模型(APM)
【.NET Core】深入理解异步编程模型(APM)
107 1
|
开发框架 移动开发 前端开发
ASP.NET MVC中使用jQuery Ajax通过FormData对象异步提交图片文件到服务端保存并返回保存的图片路径
ASP.NET MVC中使用jQuery Ajax通过FormData对象异步提交图片文件到服务端保存并返回保存的图片路径
285 0
|
开发框架 前端开发 JavaScript
[原创]Asp.net Mvc异步
[原创]Asp.net Mvc异步
[原创]Asp.net Mvc异步
|
编译器 vr&ar C#
.Net异步编程详解入门
.Net异步编程详解入门目录 前言异步编程不同模式一、异步模式二、基于事件的异步模式三、基于任务的异步模式异步编程的基础一、创建任务二、调用异步方法三、使用Awaiter四、延续任务五、多个异步方法的使用六、使用ValueTasks七、转换异步模式异步编程的错误处理一、异步方法的异步处理二、多个异步方法的异步处理三、使用AggregateException总结 回到顶部前言  今天周五,早上起床晚了。
745 0
|
.NET 数据库 开发框架
asp.net core异步进行新增操作并且需要判断某些字段是否重复的三种解决方案
之前碰到asp.net core异步进行新增操作并且需要判断某些字段是否重复的问题,进行插入操作的话会导致数据库中插入重复的字段!下面把我的解决方法记录一下,如果对您有所帮助,欢迎拍砖! 场景:EFCore操作MySql数据库的项目,进行高并发插入操作 需求:消息队列,最后进行新增数据的操作,插入前判断某些字段是否重复 问题:采用await db.SaveChangesAsync()进行提交操作前,FirstOrDefault判断数据库中是否有重复数据。
1726 0