如何封装Foo的IsStarted判定逻辑，同时支持领域层与Linq-to-Entities查询

以下是几种可落地的实现方案，均能保证「已启动」状态的定义唯一，同时兼容内存调用和EF查询转换：

方案1：抽离公共表达式树（无额外依赖，兼容性最高） #

将判定逻辑封装为静态的Expression<Func<Foo, bool>>成员，同时提供内存场景调用的属性适配：

internal sealed class Foo
{
    public Foo(DateTimeOffset start)
    {
        Start = start;
    }

    public DateTimeOffset Start { get; }

    // 统一的判断逻辑表达式，EF查询直接使用
    public static readonly Expression<Func<Foo, bool>> IsStartedFilter = f => f.Start < DateTimeOffset.UtcNow;
    
    // 缓存编译后的委托，避免每次调用都编译的性能损耗
    private static readonly Func<Foo, bool> _isStartedFunc = IsStartedFilter.Compile();
    
    // 内存场景直接调用的属性
    public bool IsStarted => _isStartedFunc(this);
}

查询时直接引用静态表达式即可：

var entities = _someDatabaseContext.Foos.Where(Foo.IsStartedFilter);

优势：不需要任何第三方依赖，兼容所有EF版本，逻辑完全唯一；劣势：查询写法不能直接在lambda内写foo.IsStarted，需要引用静态成员。

方案2：EF Core 7.0+ 原生成员翻译（写法最贴合需求） #

EF Core 7.0及以上版本支持自定义未映射属性的查询翻译逻辑，你可以直接按照预期写foo => foo.IsStarted，只需要在DbContext的OnModelCreating中配置翻译规则：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Foo>()
        .Property(f => f.IsStarted)
        // 配置该属性对应的查询翻译逻辑
        .HasConversion(v => v, v => v)
        .HasExpression(f => f.Start < DateTimeOffset.UtcNow);
}

优势：完全符合你想要的查询写法，不需要修改现有调用逻辑；劣势：仅支持EF Core 7.0及以上版本。

方案3：数据库计算列映射 #

直接将IsStarted映射为数据库的非持久化计算列，让数据库层面统一判断逻辑：

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Foo>()
        .Property(f => f.IsStarted)
        // 这里的SQL根据你使用的数据库方言调整，示例为SQL Server写法
        .HasComputedColumnSql("CASE WHEN Start < SYSUTCDATETIMEOFFSET() THEN 1 ELSE 0 END", stored: false);
}

优势：逻辑完全下沉到数据库，不会出现内存判断和查询判断不一致的问题；劣势：逻辑和数据库方言绑定，更换数据库需要修改配置。

方案4：使用LinqKit表达式展开（兼容旧版EF，写法简洁） #

引入第三方库LinqKit，它可以自动将属性调用展开为EF能识别的表达式树，你只需要在查询时加上AsExpandable()：

var entities = _someDatabaseContext.Foos.AsExpandable().Where(foo => foo.IsStarted);

优势：写法简洁，兼容大部分EF版本；劣势：需要额外引入第三方依赖。

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