問題概述：

?? 　　首先看下圖，有客戶表和客戶負(fù)責(zé)人表關(guān)系是多對多，訪問數(shù)據(jù)庫使用的是EF所以這里我們開啟了延遲加載，需求就是將每個客戶的所有負(fù)責(zé)人逗號拼接顯示在負(fù)責(zé)人這一欄位，

???????? 對你沒看錯需求就是這么簡單如果是寫sql也許我們會去用兩個循環(huán)去做，問題是要用linq實現(xiàn)。

?

?

這是我起初的寫法：

首先申明這個resultlist接收到的類型本該是Iqueryable<Customer> 但我們要放入PrincipalNames字段(逗號拼接顯示字段)所以接收的是匿名類型 這樣寫報的錯是：

大概意思：LINQ實體不能識別方法的系統(tǒng)。字符串連接(系統(tǒng)。system . String[])字符串,的方法,這種方法不能被翻譯成一個存儲表達(dá)式

然后各種百度谷歌發(fā)現(xiàn)其原因是將這段linq翻譯成sql的時候string.Join()方法不被識別也就是沒法翻譯，這時我就郁悶了，甚至懷疑linq

能不能實現(xiàn)這樣的需求、

中途有想過不用linq實現(xiàn)，用兩個循環(huán)賦值去實現(xiàn)實現(xiàn)：做法就是先循環(huán)客戶信息再循環(huán)客戶下的負(fù)責(zé)人將負(fù)責(zé)人的名稱拼接賦值給客戶的負(fù)責(zé)人

但由于前面客戶是匿名類型PrincipalNames并不存在客戶表中所以不能賦值，so解決方案就是還要在建立一個含有PrincipalNames字段的視圖模型

這樣才能循環(huán)后去賦值！我也是醉了，咋這麻煩。

又想了想不可能啊 這樣的需求很正常不是嗎linq怎么可能不能實現(xiàn)，繼續(xù)找~

在博客園找都一篇闡述IEnumerable和IQueryable區(qū)別的文章：http://www.cnblogs.com/FlyEdward/archive/2010/02/01/Linq_ExpressionTree2.html

感覺有點意思繼續(xù)找類似的文章佐證，發(fā)現(xiàn)還真是這東西在作怪 ，先看看正確的查詢寫法：

重點就在我劃紅線的地方這樣寫resultlist接收的類型是IEnumberable<Customer>類型這樣寫其會先將數(shù)據(jù)全部查入內(nèi)存中在進(jìn)行查詢，并沒有將

后面的條件也就是匿名類里面的東西包括string.Join方法翻譯成sql 這樣就不會出現(xiàn)之前不能string.Join（）方法不識別的問題了，OK解決！

總結(jié)：

IQueryable繼承自IEnumerable，所以對于數(shù)據(jù)遍歷來說，它們沒有區(qū)別。

1.IEnumerable查詢必須在本地執(zhí)行.并且執(zhí)行查詢前我們必須把所有的數(shù)據(jù)加載到本地.而且更多的時候.加載的數(shù)據(jù)有大量的數(shù)據(jù)是我們不需要的無效數(shù)據(jù).但是我們卻不得不傳輸更多的數(shù)據(jù).做更多的無用功。
使用IEnumerable，所有對于IEnumerable的過濾，排序等操作，都是在內(nèi)存中發(fā)生的。也就是說數(shù)據(jù)已經(jīng)從數(shù)據(jù)庫中獲取到了內(nèi)存中，只是在內(nèi)存中進(jìn)行過濾和排序操作。

2.IQueryable卻總能只提供你所需要的數(shù) 據(jù).大大減少了數(shù)據(jù)的傳輸
IQueryable的優(yōu)勢是它有表達(dá)式樹，所有對于IQueryable的過濾，排序等操作，都會先緩存到表達(dá)式樹中，只有當(dāng)真正遍歷發(fā)生的時候，才會將表達(dá)式樹由IQueryProvider執(zhí)行獲取數(shù)據(jù)操作。

以上觀點屬個人領(lǐng)悟，若有問題歡迎糾正。

?

轉(zhuǎn)載于:https://www.cnblogs.com/fighting2014/p/4239723.html

總結(jié)

以上是生活随笔為你收集整理的一个简单问题引发对IEnumerable和IQueryable的思考的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。