隨著平台資料的積累，對於資料訪問的速度要求愈來愈高。優化後台訪問效能，將是之後的乙個重點任務。
但是，後台在專案開發初期採用的是abp(lite ddd)框架，整合enityframework。因為之前的專案經驗有用過ef，對於開發者編碼來說，著實高效。但是之前所處傳統行業，對於資料訪問的效能要求並不高。因此也就沒有在意ef的效能問題。然後，有句話叫做「出來混，早晚要還的」。這不，現在的web專案對於資料訪問效能有些吃力了，尤其是涉及使用linq拼寫出的組合查詢且資料量大時，查詢速度慢了下來。
最近也是在一邊完成新功能的開發，一邊通過優化語法進而優化查詢速度。但是，這兩天後台倉儲層呼叫自帶api查詢資料的奇葩表現令我甚是無奈。在新功能（使用websocket實時推動資料）的介面中，呼叫後台乙個查詢裝置資訊的介面，死活查不到實體資料。然後，呼叫同樣的介面在其他介面卻可以實現。不禁令我對該框架產生了很大的疑惑，why?
不過現在的主要任務是盡快交付功能，我把問題記下了。
為了實現在當前介面呼叫查詢裝置資訊的介面可以查到資料，我注釋掉了services層對repository層的呼叫abp.enityframework自帶的api查詢資料，改用組織sql語句執行查詢、刪除、新增。結果則是正常的可以得到你想要的資料。不禁感慨啊，那些個orm不是萬能的，純碎的sql是那麼的簡單高效。
下面貼出ef中使用sql執行查詢、刪除及新增的用法：
a，查詢，
var parameter = new sqlparameter("
@deviceid
", id);
var sqldeviceinfo = string.format(@"
select * from dbo.deviceinfos where dbo.deviceinfos.id=@deviceid");
var deviceinfo = await context.database.sqlquery(sqldeviceinfo, new sqlparameter("
@deviceid
", id)).firstordefaultasync();
b。刪除
var deviceidparamter = new sqlparameter("
@deviceid
", deviceid);
var sqldeleteid = string.format(@"
delete from dbo.deviceandhiddentroublelinks where deviceid=@deviceid");
var result = await context.database.executesqlcommandasync(sqldeleteid, deviceidparamter);
c、新增
var sqladdid = string.format(@"insert into dbo.deviceandhiddentroublelinks(deviceid,devicehiddentrouble_id) values (@deviceid,@hiddentroubleid)");
foreach (var hiddentroubleid in
devicehiddentroubleids)
, new sqlparameter };
await
context.database.executesqlcommandasync(sqladdid, deviceidandhiddentroubleidparamter);
}
改完之後發現，直接使用sql挺爽的。看來後台效能優化又多了條路子。
EF中使用SQL語句或儲存過程
1 無引數查詢 varmodel db.database.sqlquery select from userinfoes tolist 2 有參查詢 varmodel db.database.sqlquery select from userinfoes where id id newsqlpara...
在EF中直接執行SQL命令
通過將objectcontext.connection轉換為entityconnection，再把 entityconnection.storeconnection轉換為sqlconnection。有了這個sqlconnection，我們再建立 sqlcommand便能順利執行sql命令了。例如 u...
在pandas中使用sql
from pandasql import sqldf 查詢記憶體中的pandas資料框 pysqldf lambda q sqldf q,globals 匯入模組，自帶資料，尋找pandas資料框 from pandasql import sqldf,load meat,load births py...