實體框架4.1性能與查詢中

問題是這樣的使用邏輯，我有一個屬性的實體：實體框架4.1性能與查詢中

public bool Expired 
    { 
     get { return CreationDate.AddDays(30) < DateTime.UtcNow; }    
    }

當然，在實體框架的查詢我不能使用它，雖然它不包含EF無法處理的任何事情，只是它甚至不嘗試。

的問題是，是否有可能保持這種微型查詢的性能在某種程度上在實體（例如使用Func<T, bool>），用於形成更復雜的查詢重用，像

Products.Where(x.Expired || x.Price > something)

UPDATE：哦，發佈後的問題，我試着在谷歌幾個查詢，發現這個：

http://damieng.com/blog/2009/06/24/client-side-properties-and-any-remote-linq-provider

它需要一些額外的代碼，所以我寫了CompiledExpression使用提到的lib像這樣對我的財產：

private static readonly CompiledExpression<GuaranteeTransaction, bool> ShouldBeExpiredExpression = 
     DefaultTranslationOf<GuaranteeTransaction> 
     .Property(x => x.ShouldBeExpired) 
     .Is(x => x.CreationDate < DateTime.UtcNow.AddDays(-30));

而事實證明，AddDays也不支持實體框架。我想我可以創建另一個CompiledExpression來使用相同的機制替換DateTime.UtcNow.AddDays（-30）屬性，但這會很荒謬（就可讀性和複雜性而言）。

來源

2011-11-02 Giedrius

*它只是不嘗試* - 簡單的EF不會嘗試它，因爲它需要評估屬性內編譯指令的含義。編譯代碼和表達式樹有很大的區別。 –

您是否試過在表達式外抓取'DateTime.UtcNow.AddDays'，並將值傳遞給表達式？另外，我發現了一些類似的代碼，可以使您逐步建立查詢。它可能會幫助你解決你的問題。看看我對這個問題的回答：http://stackoverflow.com/questions/1424251/entitysett-wheremypredicate-throws-notsupportedexception –

只要我沒有收到更好的答案，我就保持簡單：將可重用的表達式移到存儲庫。它可能看起來並不那麼幹淨，可能不是最好的地方，但他們正在做他們的工作，並沒有帶來額外的複雜性，所以我想這是相當不錯的解決方案。

來源

2011-11-04 06:47:05 Giedrius

實體框架4.1性能與查詢中

回答

相關問題