Ho cercato le differenze tra le 2 coppie di cui sopra, ma non ho trovato alcun articolo che spieghi chiaramente al riguardo e quando utilizzare l'una o l'altra.

Allora qual è la differenza tra SaveChanges()e SaveChangesAsync()?
E tra Find()e FindAsync()?

Sul lato server, quando usiamo Asyncmetodi, dobbiamo anche aggiungere await. Quindi, non penso che sia asincrono sul lato server.

Aiuta solo a prevenire il blocco dell'interfaccia utente sul browser lato client? O ci sono pro e contro tra di loro?

Ogni volta che è necessario eseguire un'azione su un server remoto, il programma genera la richiesta, la invia, quindi attende una risposta. Userò SaveChanges()e SaveChangesAsync()come esempio, ma lo stesso vale per Find()e FindAsync().

Supponi di avere un elenco myListdi oltre 100 elementi che devi aggiungere al tuo database. Per inserirlo, la tua funzione sarebbe simile a questa:

using(var context = new MyEDM())
{
    context.MyTable.AddRange(myList);
    context.SaveChanges();
}

Per prima cosa crei un'istanza di MyEDM, aggiungi l'elenco myListalla tabella MyTable, quindi chiama SaveChanges()per rendere persistenti le modifiche al database. Funziona come vuoi, i record vengono salvati, ma il tuo programma non può fare nient'altro fino al termine del commit. Questo può richiedere molto tempo a seconda di ciò che stai impegnando. Se stai effettuando il commit delle modifiche ai record, l'entità deve eseguire il commit di quelle una alla volta (una volta ho avuto un salvataggio che richiedeva 2 minuti per gli aggiornamenti)!

Per risolvere questo problema, potresti fare una delle due cose. Il primo è che puoi avviare un nuovo thread per gestire l'inserto. Mentre questo libererà il thread chiamante per continuare l'esecuzione, hai creato un nuovo thread che rimarrà lì e aspetta. Non c'è bisogno di quel sovraccarico, e questo è ciò che lo async awaitschema risolve.

Per le operazioni di I / O, awaitdiventa rapidamente il tuo migliore amico. Prendendo la sezione del codice dall'alto, possiamo modificarla in modo che sia:

using(var context = new MyEDM())
{
    Console.WriteLine("Save Starting");
    context.MyTable.AddRange(myList);
    await context.SaveChangesAsync();
    Console.WriteLine("Save Complete");
}

È un cambiamento molto piccolo, ma ci sono effetti profondi sull'efficienza e sulle prestazioni del codice. Allora cosa succede? L'inizio del codice è lo stesso, crei un'istanza di MyEDMe aggiungi il tuo myLista MyTable. Ma quando si chiama await context.SaveChangesAsync(), l'esecuzione del codice ritorna alla funzione chiamante! Quindi, mentre aspetti che tutti quei record vengano salvati, il tuo codice può continuare a essere eseguito. Supponiamo che la funzione che conteneva il codice precedente avesse la firma di public async Task SaveRecords(List<MyTable> saveList), la funzione chiamante potrebbe essere simile a questa:

public async Task MyCallingFunction()
{
    Console.WriteLine("Function Starting");
    Task saveTask = SaveRecords(GenerateNewRecords());

    for(int i = 0; i < 1000; i++){
        Console.WriteLine("Continuing to execute!");
    }

    await saveTask;
    Console.Log("Function Complete");
}

Perché avresti una funzione come questa, non lo so, ma ciò che produce mostra come async awaitfunziona. Per prima cosa esaminiamo cosa succede.

L'esecuzione entra MyCallingFunction, Function Startingquindi Save Startingviene scritta sulla console, quindi la funzione SaveChangesAsync()viene chiamata. A questo punto, l'esecuzione ritorna MyCallingFunctioned entra nel ciclo for scrivendo 'Continuing to Execute' fino a 1000 volte. Al SaveChangesAsync()termine, l'esecuzione ritorna alla SaveRecordsfunzione, scrivendo Save Completesulla console. Una volta che tutto è stato SaveRecordscompletato, l'esecuzione continuerà nel modo MyCallingFunctioncorretto dove era al SaveChangesAsync()termine. Confuso? Ecco un esempio di output:

Avvio della funzione
Salva avvio
Continuando a eseguire!
Continuando a eseguire!
Continuando a eseguire!
Continuando a eseguire!
Continuando a eseguire!
....
Continuando a eseguire!
Salva completato!
Continuando a eseguire!
Continuando a eseguire!
Continuando a eseguire!
....
Continuando a eseguire!
Funzione completa!

O forse:

Avvio della funzione
Salva avvio
Continuando a eseguire!
Continuando a eseguire!
Salva completato!
Continuando a eseguire!
Continuando a eseguire!
Continuando a eseguire!
....
Continuando a eseguire!
Funzione completa!

Questa è la bellezza di async await, il tuo codice può continuare a funzionare mentre aspetti che qualcosa finisca. In realtà, avresti una funzione più simile a questa come funzione chiamante:

public async Task MyCallingFunction()
{
    List<Task> myTasks = new List<Task>();
    myTasks.Add(SaveRecords(GenerateNewRecords()));
    myTasks.Add(SaveRecords2(GenerateNewRecords2()));
    myTasks.Add(SaveRecords3(GenerateNewRecords3()));
    myTasks.Add(SaveRecords4(GenerateNewRecords4()));

    await Task.WhenAll(myTasks.ToArray());
}

Qui sono disponibili quattro diverse funzioni di salvataggio dei record contemporaneamente . MyCallingFunctionsi completerà molto più velocemente usando async awaitche se le singole SaveRecordsfunzioni fossero chiamate in serie.

L'unica cosa che non ho ancora toccato è la awaitparola chiave. Ciò che fa è interrompere l'esecuzione della funzione corrente fino al completamento di tutto ciò Taskche stai aspettando. Quindi, nel caso dell'originale MyCallingFunction, la riga Function Completenon verrà scritta sulla console fino al SaveRecordstermine della funzione.

Per async awaitfarla breve, se hai un'opzione da usare , dovresti in quanto aumenterà notevolmente le prestazioni della tua applicazione.

La mia restante spiegazione sarà basata sul seguente frammento di codice.

using System;
using System.Threading;
using System.Threading.Tasks;
using static System.Console;

public static class Program
{
    const int N = 20;
    static readonly object obj = new object();
    static int counter;

    public static void Job(ConsoleColor color, int multiplier = 1)
    {
        for (long i = 0; i < N * multiplier; i++)
        {
            lock (obj)
            {
                counter++;
                ForegroundColor = color;
                Write($"{Thread.CurrentThread.ManagedThreadId}");
                if (counter % N == 0) WriteLine();
                ResetColor();
            }
            Thread.Sleep(N);
        }
    }

    static async Task JobAsync()
    {
       // intentionally removed
    }

    public static async Task Main()
    {
       // intentionally removed
    }
}

Caso 1

static async Task JobAsync()
{
    Task t = Task.Run(() => Job(ConsoleColor.Red, 1));
    Job(ConsoleColor.Green, 2);
    await t;
    Job(ConsoleColor.Blue, 1);
}

public static async Task Main()
{
    Task t = JobAsync();
    Job(ConsoleColor.White, 1);
    await t;
}

Note: poiché la parte sincrona (verde) dei JobAsyncgiri più lunga dell'attività t(rossa), l'attività tè già completata al punto di await t. Di conseguenza, la continuazione (blu) viene eseguita sullo stesso thread di quella verde. La parte sincrona di Main(bianco) girerà dopo che quella verde avrà finito di girare. Ecco perché la parte sincrona nel metodo asincrono è problematica.

Caso 2

static async Task JobAsync()
{
    Task t = Task.Run(() => Job(ConsoleColor.Red, 2));
    Job(ConsoleColor.Green, 1);
    await t;
    Job(ConsoleColor.Blue, 1);
}

public static async Task Main()
{
    Task t = JobAsync();
    Job(ConsoleColor.White, 1);
    await t;
}

Osservazioni: questo caso è opposto al primo. La parte sincrona (verde) di JobAsyncgiri più breve dell'attività t(rossa) quindi l'attività tnon è stata completata al punto di await t. Di conseguenza, la continuazione (blu) viene eseguita sul thread diverso come quello verde. La parte sincrona di Main(bianco) gira ancora dopo che quella verde ha finito di girare.

Caso 3

static async Task JobAsync()
{
    Task t = Task.Run(() => Job(ConsoleColor.Red, 1));
    await t;
    Job(ConsoleColor.Green, 1);
    Job(ConsoleColor.Blue, 1);
}

public static async Task Main()
{
    Task t = JobAsync();
    Job(ConsoleColor.White, 1);
    await t;
}

Note: questo caso risolverà il problema nei casi precedenti sulla parte sincrona nel metodo asincrono. Il compito tè immediatamente atteso. Di conseguenza, la continuazione (blu) viene eseguita sul thread diverso come quello verde. La parte sincrona di Main(bianco) ruoterà immediatamente parallelamente a JobAsync.

Se desideri aggiungere altri casi, sentiti libero di modificare.

Questa affermazione non è corretta:

Sul lato server, quando usiamo metodi Async, dobbiamo anche aggiungere await.

Non è necessario aggiungere "await", awaitè semplicemente una comoda parola chiave in C # che consente di scrivere più righe di codice dopo la chiamata e quelle altre righe verranno eseguite solo dopo il completamento dell'operazione di salvataggio. Ma come hai sottolineato, potresti farlo semplicemente chiamando SaveChangesinvece di SaveChangesAsync.

Ma fondamentalmente, una chiamata asincrona è molto più di questo. L'idea qui è che se c'è altro lavoro che puoi fare (sul server) mentre l'operazione di salvataggio è in corso, allora dovresti usare SaveChangesAsync. Non utilizzare "wait". Chiama SaveChangesAsynce poi continua a fare altre cose in parallelo. Ciò include potenzialmente, in un'app Web, la restituzione di una risposta al client anche prima del completamento del salvataggio. Ma ovviamente, vorrai comunque controllare il risultato finale del salvataggio in modo che, nel caso in cui fallisca, puoi comunicarlo al tuo utente o registrarlo in qualche modo.