Net Core：实体框架中的通用存储库主 ID 键性能

Question

我们正在审查通用存储库模式中的两种不同方法。 目前，想要将主键映射到 Id。这样做的目的是映射到使用 Id 的通用存储库接口。下面提供了两种解决方案。

.FindPrimaryKey().Properties 对性能有何影响。在尝试查找主键时是否会导致数据库表的模式锁定？它会导致任何应用程序缓慢吗？

与部分类方法解决方案 2 相比，它的性能如何？ 哪个选项在性能方面更好？

注意：架构师要求在工作场所使用存储库模式，因此实施它。知道围绕这个问题存在争议，但不是我的呼吁。

脚手架模型示例：

namespace Datatest
{
    public partial class Property
    {
        public int Property { get; set; }
        public int DocumentId { get; set; }
        public string Address { get; set; }
    }
}

所有表的示例通用基础存储库：

    public T Get(int id)
    {
        return Table.Find(id);
    }
    public async Task<T> GetAsync(int id)
    {
        return await Table.FindAsync(id);
    }
    public T Single(Expression<Func<T, bool>> predicate)
    {
        return All.Single(predicate);
    }
    public async Task<T> SingleAsync(Expression<Func<T, bool>> predicate)
    {
        return await All.SingleAsync(predicate);
    }
    public T FirstOrDefault(int id)
    {
        return All.FirstOrDefault(CreateEqualityExpressionForId(id));
    }

解决方案 1：FindPrimaryKey()

Generic Repository in C# Using Entity Framework

使用 EF FindPrimaryKey()

var idName = _context.Model.FindEntityType(typeof(TEntity))
        .FindPrimaryKey().Properties.Single().Name;

解决方案 2：部分类映射

Net Core: Create Generic Repository Interface Id Mapping for All Tables Auto Code Generation

public partial class Property: IEntity
{
    [NotMapped]
    public int Id { get => PropertyId; set => PropertyId = value; }
}

Answer 1

关于第一种方法（使用 EF Core 元数据服务）：

首先，EF Core 是 ORM（Object Relational Mapper），这里最重要的是 Mapper。

其次，它使用所谓的基于代码的模型，这意味着所有的映射都是由代码而不是实际的数据库提供的（即使模型是通过现有数据库的逆向工程创建的） .

简而言之，EF Core 在运行时创建一个内存数据结构，其中包含有关类和属性的信息（元数据），以及它们到数据库表、列和关系的映射。所有这些信息都基于纯代码模型——实体类、约定、数据注释和流畅的配置。

所有 EF Core 运行时行为都基于该元数据模型。 EF Core 在内部使用它来构建查询、将查询结果映射到对象、链接导航属性、生成创建/更新/删除命令及其执行顺序、在获取真正的自动生成的主键值后更新临时 FK 属性值等。

因此元数据模型和发现服务（方法）使用优化的数据结构并且（必须）非常高效。同样，不涉及任何数据库操作。

所以第一种方法非常有效。与实际的查询构建、执行和实现相比，通过元数据服务获取 PK 属性 名称对性能的影响可以忽略不计。

第一种方法的性能也类似于您在另一种方法中使用的 EF Core Find 方法。请注意，在调用 Find 方法时，您只需传递 PK 值而不是属性。所以方法实现应该知道如何构建Where 表达式，对吧？而且它在内部的作用与建议的 sn-p 非常相似。

---

关于第二种方法：

它根本无法比较，因为它不起作用。可以使用基类/接口，但前提是映射了实际的属性名称 - 就像所有类都具有 Id 属性，并且使用 [Column] 映射到数据库表中的不同 列名数据注释或HasColumnName fluent API。

在您的示例中，Id 属性为[NotMapped]（忽略）。这意味着 EF Core 无法映射到表列。您通过代码将其映射到另一个属性（属性 getter/setter）这一事实并不重要。 EF Core 不是一个（反）编译器，它看不到您的代码，因此无法将使用此类属性的 LINQ 查询转换为 SQL。

在 EF Core 2.x 中会导致 client evaluation（非常低效，读取整个表并在内存中应用过滤器），或者如果客户端评估为 configured to do so 则异常。在 EF Core 3.0+ it will always be an exception.

因此，如果您不删除 PropertyId 和 ma​​p 属性 Id 之类的属性（这对于“数据库优先”模型来说很难），那么第二个“方法”应该是避免。即使您可以映射实际的Id 属性，您所节省的只是几毫秒。再说一次，当使用 Find 时，您不必担心性能，为什么还要使用使用相同（或相似）方法的方法。