隨著平臺數據的積累，對於數據訪問的速度要求愈來愈高。優化後臺訪問性能，將是之後的一個重點任務。

但是，後臺在項目開發初期采用的是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<DeviceInfo>(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)
                {
                    var deviceIdAndHiddenTroubleIdParamter = new DbParameter[] { new SqlParameter { ParameterName = "DeviceId", Value = deviceId }, new SqlParameter { ParameterName = "HiddenTroubleId", Value = hiddenTroubleId } };
                    await Context.Database.ExecuteSqlCommandAsync(sqlAddId, deviceIdAndHiddenTroubleIdParamter);
                }

改完之後發現，直接使用SQL挺爽的。看來後臺性能優化又多了條路子。

在EF中使用SQL執行簡單高效的增刪查操作