扩展EF Core实体类（添加非列属性）是否不明智？

CastleProxy代理对EF Core（SQL Server）的行为影响 #

先明确你的实体类结构：

原实体类：

public partial class TableA
{
  public int TableAId { get; set; }
}

public partial class TableB
{
  public int TableBId { get; set; }
}

显式实现IId接口的部分类：

public interface IId
{
  int Id { get; set; }
}

public partial class TableA : IId
{
  int IId.Id { get => this.TableAId; set => this.TableAId = value; }
}

public partial class TableB : IId
{
  int IId.Id { get => this.TableBId; set => this.TableBId = value; }
}

当这些类被CastleProxy替换为动态代理实例后，对EF Core的核心行为几乎没有破坏性影响，具体细节如下：

• 数据库映射完全不受影响
  EF Core是基于实体的公共属性（TableAId、TableBId）配置数据库映射的，你显式实现的IId.Id属于接口隐式成员，EF Core不会自动将其映射到数据库列。代理类会完整继承原类的公共属性和接口实现，所以主键与数据库列的对应关系、CRUD操作都和原来一致。

• 接口调用逻辑正常生效
  把代理实例转换为IId接口后，通过Id属性读取或修改值的操作，会被代理类转发到原类的显式实现逻辑，最终还是操作TableAId/TableBId属性，不会出现逻辑断裂。

• 变更追踪工作正常
  EF Core的变更追踪依赖属性的get/set操作触发。不管是直接操作TableAId，还是通过IId.Id接口操作，最终都会触发原属性的setter，EF Core能正常捕捉到属性变更，代理类不会干扰这一过程。

• 延迟加载（若有）无冲突
  如果后续给实体添加了virtual导航属性，CastleProxy生成的代理类会正常实现延迟加载逻辑，这和IId接口的实现完全独立，不会产生冲突。

• 类型检查需注意小细节
  代理实例的GetType()会返回Castle生成的子类类型（比如Castle.Proxies.TableAProxy），但用is TableA或is IId做类型判断依然会返回true。如果业务代码里有依赖具体类型的逻辑，要避免直接比较Type对象，但EF Core本身不依赖实体的具体类型，所以这不会影响EF Core的核心功能。

内容的提问来源于stack exchange，提问作者Dee J. Doena