在使用WebService開發時，同時使用了EF和linq，查詢數據時，使用linq（查詢訂單）可以正常拉出數據，
但是使用EF（查詢用戶）卻會報以下錯誤：
{"指定的架構無效。錯誤: \r\nCLR 類型到 EDM 類型的映射不明確，因為多個 CLR 類型與 EDM 類型“Orders”匹配。以前找到的是 CLR 類型“WebService1.Model.Orders”，新找到的則是 CLR 類型“WebService1.LinqModel.Orders”。\r\nCLR 類型到 EDM 類型的映射不明確，因為多個 CLR 類型與 EDM 類型“Users”匹配。以前找到的是 CLR 類型“WebService1.Model.Users”，新找到的則是 CLR 類型“WebService1.LinqModel.Users”。"}
DbContext的MetadataWorkSpace一旦生成會緩存起來。也就是說，在同一個應用程序域里面，一旦用dbcontext操作過數據庫，它會自動讀取類所在assembly里面的所有類，並嘗試匹配數據庫模型，然后將匹配結果保存起來(保存到上面的MetaOCSpace中)。當下次操作數據庫時，返回數據對應類類所在其它assembly里面的類與當前已匹配數據庫模型發生沖突時，便會報錯。（這段話是網上抄的）
在ASP.NET MVC5高級編程（第5版）中第70頁作者寫到：
實體框架的另一種（默認的）策略是延遲加載策略。使用延遲建在策略，EF在LINQ查詢中只加載主要對象（專輯）的數據，而不填充Genre和Artist屬性。
var albums=db.Albums;
延遲加載根據需要來加載相關數據，也就是說，只有當Album的Genre或Artist需要屬性時，EF才會公國向數據庫發送一個個額外的查詢來加載這些數據。延遲加載策略會強制框架未列表中每一個專輯向數據庫發送一個額外的查詢。
參考上面的解釋和報錯信息，還是不太清楚他們的內部運行原理（需要繼續研究），但是已經知道如何解決了。
解決方案：不要生成相通的模型，可以修改linq模型名稱。
修改后：
問題得到解決。