Best performance ASP.NET CORE 2.1

Question

I'm new to ASP.NET CORE and I wanted to know which of these is the best for performance and scalability and design wise:

Case 1:

[HttpPost]
public async Task CreateBook([FromBody] Book book)
{
    _context.Add(book);
    await _context.SaveChangesAsync();
}

Case 2:

[HttpPost]
public async Task CreateBook([FromBody] Book book)
{
    await _booksRepository.AddBookAsync(book);
}
//Repository class:
public async Task AddBookAsync(Book book)
{
    _context.Add(book);
    await _context.SaveChangesAsync();
}

Case 3:

  [HttpPost]
  public async Task CreateBook([FromBody] Book book)
    {
        await _booksRepository.AddBook(book);
        await _context.SaveChangesAsync();
    }
    //Repository class:
    public async Task AddBook(Book book)
    {

        _context.Add(book);
    }

Answer 1

I would use the third approach with some slight modifications. I would use Unit of Work pattern:

[HttpPost]
public async Task CreateBook([FromBody] Book book)
{
    await _booksRepository.AddBook(book);
    await _uow.Commit();
}

There are some reasons:

• repository should be just like collection of objects such as List<T>. We do not have Save method in List<T>
• using UnitOfWork allows to decouple our code to have better unit testing and we will have loose coupling
• it is simplier to write unit tests

It is not important from performance point as creating new objects is not highly cost operation. However, editing, supporting, modifications of this code will be easier and faster.

UPDATE:

_uow is a variable which will store the following method:

public class UnitOfWork : IUnitOfWork
{
    private readonly MyDbContext _dbContext;

    public async Task Commit()
    {
        await _dbContext.SaveChangesAsync();
    }
}

You can read more about Entity Framework SaveChanges() vs. SaveChangesAsync().

Reasons to use Repository and UoW pattern:

• it allows to write unit tests just by replacing result by IEnumerable<T>. So it becomes so simple to write unit tests for services without calling database code
• When we have separate business logic from repository code, then code becomes cleaner and clearer. In this case, business logic will not have big queries. So we paid attention to separation of concerns.
• cleaner and clearer architecture