Return to Answer

added 13 characters in body

Source Link

edited Dec 9, 2017 at 5:39

34.9k
13
133
237

If that Add is calling the database, then async is warranted. HoweverHowever, I think you are overcomplicating it. WithWith Async/Await, you need async/await through all the layers until you await a SaveChangesAsyncSaveChangesAsync or some bottom call. Ultimately

Ultimately, when this async fires, it'll free up the thread for something else to do work. Also, if you are using a framework, you should do .ConfigureAwait(false).ConfigureAwait(false) after all of your await calls or you could end up in deadlocks for users that force a sync call. However

However, if you need the language/culture from the original thread later in the call, then you don't want to use ConfigureAwait(false)ConfigureAwait(false), but you could always pull off the current values, run it, then update the thread values after the await call to fix that issue. Also, all the Async methods should have the word "Async" after them, except for the top level ones on the UI to make it clear.

This is how I'd lay it out:

_Repository.AddAsync_Repository.AddAsync, if using EF, would then await context.SaveChangesAsync()context.SaveChangesAsync().

If you wanted to go the extra mile, also have all methods take CancellationToken token = default(CancellationToken)CancellationToken token = default(CancellationToken) as an optional parameter and pass that all the way down, too.

If that Add is calling the database, then async is warranted. However, I think you are overcomplicating it. With Async/Await, you need async/await through all the layers until you await a SaveChangesAsync or some bottom call. Ultimately, when this async fires, it'll free up the thread for something else to do work. Also, if you are using a framework, you should do .ConfigureAwait(false) after all of your await calls or you could end up in deadlocks for users that force a sync call. However, if you need the language/culture from the original thread later in the call, then you don't want to use ConfigureAwait(false), but you could always pull off the current values, run it, then update the thread values after the await call to fix that issue. Also, all the Async methods should have the word "Async" after them, except for the top level ones on the UI to make it clear. This is how I'd lay it out:

_Repository.AddAsync, if using EF, would then await context.SaveChangesAsync().

If you wanted to go the extra mile, also have all methods take CancellationToken token = default(CancellationToken) as an optional parameter and pass that all the way down, too.

Ultimately, when this async fires, it'll free up the thread for something else to do work. Also, if you are using a framework, you should do .ConfigureAwait(false) after all of your await calls or you could end up in deadlocks for users that force a sync call.

However, if you need the language/culture from the original thread later in the call, then you don't want to use ConfigureAwait(false), but you could always pull off the current values, run it, then update the thread values after the await call to fix that issue. Also, all the Async methods should have the word "Async" after them, except for the top level ones on the UI to make it clear.

This is how I'd lay it out:

_Repository.AddAsync, if using EF, would then await context.SaveChangesAsync().

If you wanted to go the extra mile, also have all methods take CancellationToken token = default(CancellationToken) as an optional parameter and pass that all the way down, too.

Source Link

created Dec 9, 2017 at 3:54

Daniel Lorenz

public async Task<DTOUser> CreateUserAsync(DTORegister source)
{
    var result = new DTOUser();

    try
    {
        var user = new DTOUser()
        {
            Active = (int)defaultNumber.One,
            Deleted = (int)defaultNumber.Zero,
            DateCreated = DateTime.Now,
        };

        result = await _RepositoryUser.AddAsync<DTOUser, DTOUser>(user).ConfigureAwait(false);

        //This part is where I dont feel confident
        var login = new DTOLogin()
        {
            Email = source.Email,
            Password = source.Password,
            OwnerID = result.UserID, //using the result of my 1st task here. 
            DateCreated = DateTime.Now

        };

        await _RepositoryLogIn.AddAsync<DTOLogin, DTOLogin>(login).ConfigureAwait(false);

        result.IsSuccessful = true;

    }
    catch (Exception ex)
    {
        result.ErrorMsg = "BL Error - " + ex.Message;
        result.IsSuccessful = false;
    }
    return result;
}

_Repository.AddAsync, if using EF, would then await context.SaveChangesAsync().

If you wanted to go the extra mile, also have all methods take CancellationToken token = default(CancellationToken) as an optional parameter and pass that all the way down, too.