【问题标题】:Type inference in lambdaslambda 中的类型推断
【发布时间】:2014-10-16 22:17:40
【问题描述】:

我有这个功能:

 public class Repository : IRepository
    {
        public List<TEntity> GetOrdered<TEntity, TSortKey>(Func<TEntity, TSortKey> orderBy, int take, params string[] includePaths) where TEntity : AbstractEntity
        {
            var query = (from ent in this.Context.Set<TEntity>() select ent).IncludePaths(includePaths);

            return query.OrderBy(orderBy).Take(take).ToList();
        }
    }    

调用它:

List<Project> p = repository.GetOrdered<Project, string>(x => x.Name, 10);

我想在调用时消除给它第二个通用参数的需要,从 API 的角度来看,它是一个交易破坏者。

怎么做?

【问题讨论】:

    标签: c# generics types inference


    【解决方案1】:

    从 API 的角度来看,这是一个交易破坏者

    然后考虑您的交易失败...您不能部分推断通用参数。如果你的 repository 是通用的,你可以这样做:

     public class Repository<TEntity> : IRepository<TEntity> where TEntity : AbstractEntity
    {
        public List<TEntity> GetOrdered<TSortKey>(Func<TEntity, TSortKey> orderBy, int take, params string[] includePaths) 
        {
            var query = (from ent in this.Context.Set<TEntity>() select ent).IncludePaths(includePaths);
    
            return query.OrderBy(orderBy).Take(take).ToList();
        }
    }  
    

    然后做

    List<Project> p = repository.GetOrdered(x => x.Name, 10);
    

    但我不知道您是否可以进行这种更改。

    【讨论】:

    • 它不是通用的,我更喜欢这样,我觉得它可以更简单地使用。谢谢你的回答,我会+1,但拿另一个,因为它在我的架构中工作(尽管我不喜欢使用语法)。为什么他们不实施部分推理?这显然是有道理的,至少在这种情况下是这样。
    • @h.alex 因为设计、构建、测试和发布功能需要花钱。 C# 团队权衡一个特性的好处与成本,并权衡它与其他请求特性的好处。到目前为止,似乎收益不值得付出代价。另请参阅this answer 以获得其他意见。
    • 所以 MS 应该雇佣更多的架构师、开发人员和测试人员来构建每一个功能,无论其价值如何?抱歉,世界不是这样运作的。
    【解决方案2】:

    编译器可以推断所有类型参数,或者您必须全部指定。但你可以显式指定 lambda 表达式的参数类型,例如:

    List<Project> p = repository.GetOrdered((Project x) => x.Name, 10);
    

    【讨论】:

    • 我不知道我可以用 lambdas 做到这一点。谢谢!我不喜欢使用语法,但我想这是唯一可能的方法。这确实有效。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多