C# 最佳性能ASP.NET CORE 2.1

我是ASP.NET CORE的新手，我想知道以下哪项对性能、可扩展性和设计而言是最好的：

案例1：

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

案例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();
}

案例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);
    }

---

我将使用第三种方法，稍作修改。我会使用

工作单元

模式：

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

有一些原因：

• 存储库应该和对象的集合一样，比如

  List

  。我们在

  列表中没有
  保存
  方法

• 使用

  UnitOfWork

  可以使我们的代码解耦，从而进行更好的单元测试，我们将拥有松散耦合
• 编写单元测试更简单

从性能角度来看，这并不重要，因为创建新对象的操作成本不高。但是，编辑、支持和修改此代码将更容易、更快

更新：

\u uow

是一个变量，它将存储以下方法：

public class UnitOfWork : IUnitOfWork
{
    private readonly MyDbContext _dbContext;

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

使用

Repository

和

UoW

模式的原因：

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

• 它允许编写单元测试，只需将结果替换为

  IEnumerable

  。因此，为服务编写单元测试而不调用数据库代码变得非常简单
• 当我们将业务逻辑与存储库代码分开时，代码就会变得越来越清晰。在这种情况下，业务逻辑将不会有大的查询。所以我们注意了
• 更干净、更清晰的体系结构

---

你可以使用一个并自己找出答案。“程序优化的第一条规则：不要这样做。程序优化的第二条规则（仅限专家！）：暂时不要这样做。”-Michael a.Jackson忘记性能，案例2中的

AddBookAsync

是不正确的，因为它没有做你期望它做的事情。DbContext本质上是缓存所有更改的工作单元

SaveChanges

将所有这些更改存储到数据库中，而不仅仅是最新的更改

AddBookAsync

可以很容易地执行2次删除和3次更新“通用”存储库是一种反模式，

DbSet

本身执行通用存储库尝试执行的操作。DbContext本身提供了工作单元和域事务。通用存储库本身并不能证明其成本（或问题）是合理的。额外的查询方法可以很容易地添加到DbContext中。专用存储库在抽象和简化复杂业务场景时是有意义的。一种情况是将业务实体映射到不同的存储DTO。另一种情况是隐藏复杂的报告查询。请检查Gunar Peipman的@Alexbogs，请查看我更新的答案数据库集已经是存储库，DbContext已经是UoW。典型的泛型存储库是一个较低级别的抽象，当应用到更高级别的抽象（如these@Alexbogs在考虑使用额外的存储库或UOW之前，先阅读Gunar Peipman。他解释了为什么典型的存储库实现是错误的，比如“导致意外执行”。硬币的另一面是添加数据库事务以恢复UoW所引起的可伸缩性问题semantics@AlexbogsDbSet是高级抽象，它比一般的回购协议更高。Gunar Peipman的文章是构建更高层次抽象的极好起点。他随后的文章解释了如何使用eg或raw SQL命令和报告queries@Alexbogs对于有意义的单元测试，无论如何都必须使用专用接口。与其尝试模拟

iPresository.GetAll（）。其中（c=>c.Name=…）

您应该模拟

icCustomerRepo.GetByName

或

icCustomerRepo.GetByMemberCardNo（）

。否则，您将不得不将数据访问实现细节泄漏到单元测试本身中