3
Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate);
我將參數傳遞給Where方法如下:f => f.Id > 4
。 我可以通過委託方法而不是f.Id > 4
嗎?我可以在實體框架的Where方法中使用自定義委託方法嗎?
Where<TSource>(this IQueryable<TSource> source, Expression<Func<TSource, bool>> predicate);
我將參數傳遞給Where方法如下:f => f.Id > 4
。 我可以通過委託方法而不是f.Id > 4
嗎?我可以在實體框架的Where方法中使用自定義委託方法嗎?
號
實體框架必須能夠看到一切,正在嘗試。
所以,如果你只是做了這樣的事情:
queryable.Where(f => DelegateFunc(f));
凡DelegateFunc的定義是這樣的:
public bool DelegateFunc(Foo foo)
{
return foo.Id > 4;
}
實體框架沒有委託內部對等的方式,來破解它打開並將其轉換爲SQL。
雖然沒有丟失。
如果你的目標是重新使用常用的過濾器等,你可以做這樣的事情,而不是:
public Expression<Func<Foo, bool>> DelegateExpression{
get{
Expression<Func<Foo,bool>> expr = f => f.Id > 4;
return expr;
}
}
queryable.Where(DelegateExpression);
你錯了,亞歷克斯。我傳遞給Where方法如下:「queryable.Where(f => DelegateFunc);」而不是「queryable.Where(f => DelegateFunc(f));」。該語句成功執行,但返回Enumerable not Queryable。 – Linh 2010-09-24 06:22:42
我不同意。通常在執行過濾器時,您需要將其轉換爲SQL。獲取一個IEnumerable證明你不是在數據庫中執行過濾器,而是LINQ來接管它,並且你正在檢索數據庫中的每條記錄並在內存中進行過濾。可能在測試中可以正常工作,但是一旦您擁有大量數據,它將表現得非常好。基本上你只是使用EF來實現實體,這是一種反模式。 – 2010-09-24 14:16:27
你的評論是非常有用的,亞歷克斯。它以我的方式顯示了表現的缺陷。我將傳遞一個方法返回的Expression>而不是傳遞委託方法。在該方法中,我可以自定義條件。 –
Linh
2010-09-27 14:44:48