方案如下：后端：Asp.NET 核心 WebAPI 2.2前端：使用API的iOS和Android我有一個(gè)功能，允許用戶向其他用戶發(fā)送消息。消息的發(fā)送是通過異步操作完成的：public async Task<IActionResult> CreateMessage此操作按順序執(zhí)行以下操作：驗(yàn)證等待消息對(duì) DB 的持久性等待通過 SignalR 通知相關(guān)客戶端不等待通過 Azure 通知中心發(fā)送推送通知。返回 200 OK。操作中的最后兩行如下所示：_notificationHubProxy.SendNotification(messageToReturnResource.SenderName, messageToPush, recipientId);
return Ok(messageToReturnResource);SendNotification是異步的，但我選擇不等待它，以避免由于請(qǐng)求完成而導(dǎo)致UI鎖定。目前，所有這些似乎都很好。我的問題實(shí)際上是：這是okey（即不等待），還是這是編寫錯(cuò)誤代碼的示例，當(dāng)我有許多客戶端使用該應(yīng)用程序時(shí)會(huì)導(dǎo)致問題？問候
1 回答
慕森王
TA貢獻(xiàn)1777條經(jīng)驗(yàn) 獲得超3個(gè)贊
ASP.NET（核心和經(jīng)典）上的“即發(fā)即棄”存在一些問題：
任何異常都將被靜默忽略。
應(yīng)用程序無法檢測(cè)到操作何時(shí)完成。這意味著所有“高于”此代碼的東西都不知道您的代碼仍在執(zhí)行某些操作;ASP.NET、IIS 和負(fù)載均衡器都不知道您的應(yīng)用程序仍在進(jìn)行中。其中一些是可以（并且將）關(guān)閉你的應(yīng)用的管理系統(tǒng)。例如，IIS執(zhí)行定期的應(yīng)用程序池回收。
Fire and Forget on ASP.NET 的用例比大多數(shù)人想象的要罕見得多。你不僅要對(duì)默默吞咽錯(cuò)誤感到滿意，而且你還必須對(duì)偶爾失去這項(xiàng)工作感到滿意。
我選擇不等待它，以避免由于等待請(qǐng)求完成而導(dǎo)致的UI鎖定。
這聽起來像是一個(gè)應(yīng)該由UI解決方案解決的UI問題。
- 1 回答
- 0 關(guān)注
- 102 瀏覽
添加回答
舉報(bào)
0/150
提交
取消