如何在泛型方法中使用LINQ Where？解决ParentId无法识别问题

这个问题我之前也碰到过，核心原因是编译器没办法在编译期确认你的泛型类型T确实包含ParentId属性——哪怕你知道所有T都有这个属性，但编译器只认你给它的约束条件，现在你的约束只有where T : new()，它完全不知道ParentId的存在，自然会报错。

下面是最优雅且类型安全的解决方案：

步骤1：定义统一接口约束 #

先创建一个接口，明确声明ParentId属性，用来规范所有需要传入这个泛型方法的类型：

public interface IHasParentId
{
    Guid ParentId { get; }
}

步骤2：让目标类型实现这个接口 #

确保所有你要用到的T类型，都实现上面的IHasParentId接口，比如你的实体类可以这么写：

public class Product : IHasParentId
{
    public Guid ParentId { get; set; }
    // 其他业务属性...
}

步骤3：更新泛型方法的约束 #

修改你的GetItems<T>方法，把接口添加到泛型约束里，这样编译器就明确知道T必然包含ParentId属性了：

public static List<T> GetItems<T>(Guid parentId = new Guid()) where T : new(), IHasParentId
{
    var db = new SQLiteConnection(_dbPath);
    List<T> result;
    if (parentId != Guid.Empty)
    {
        // 现在编译器能正常解析ParentId了
        result = db.Table<T>().Where(i => i.ParentId.Equals(parentId)).ToList();
    }
    else
    {
        result = db.Table<T>().ToList();
    }
    db.Close();
    return result;
}

为什么这个方案靠谱？ #

通过接口约束，你相当于给编译器开了“绿灯”：所有传入这个方法的T类型，都必须遵守接口约定，也就必然拥有ParentId属性。这样既保证了编译期的类型检查，又不会影响运行时性能，是泛型场景下的标准解决方案。

不推荐的备选方案（仅作参考） #

如果因为某些历史原因没法给T类型加接口，你也可以用反射来访问ParentId，但这种方式会损失编译期检查，还会拖慢性能，示例如下：

result = db.Table<T>().Where(i => 
    ((Guid)typeof(T).GetProperty("ParentId").GetValue(i)).Equals(parentId)
).ToList();

除非万不得已，否则千万别用这种方式，接口约束才是最优解。

内容的提问来源于stack exchange，提问作者lepton