1樓：john0king
Blazor server 你值得擁有！想象客戶端(vue angular)一樣寫介面，象服務點一樣安全的訪問資料庫麼？沒錯你可以，現在你只需要乙個.
net 5 SDK 和乙個 terminal ，馬上開始吧
2樓：程式設計師生活圈
所以兩年前的時候推出了乙個新的應用層協議：RSocket，它可以完成 http 和 socket 能完成的所有事。現在生態也越來越好了，Spring boot 對他也有了支援，而 Spring boot 2.
3.x 版本中的 Spring Security 也對他有了「飛躍性」的支援。
3樓：無阻SOFT
果然web開發的人都不去了解協議本身嗎。
這種以長連線作為客戶端與後端處理協議的軟體桌面版不是都被玩爛了嗎。
c/s模式的開發常用模式在b/s上肯定是可行的啊
4樓：易哥
問題有點模糊不清，WebSocket是個通訊協議，Controller是後端介面，兩者概念不對等，不存在替換關係。
是問「WebSocket能否完全替代HTTP作為前後端通訊協議麼？」
如果是這樣的話，這個問題可以轉換為另乙個問題：「雙向通訊能否完全替代單向通訊？」
答案是顯然的，絕對沒問題！
不過也要注意一點，WebSocket在前期協議協商環節用到了HTTP協議，這是為了相容性而設計的。即，使用WebSocket時，雙方先採用HTTP通訊，使用HTTP通訊握手並確定對方都支援WebSocket後，才切換到WebSocket繼續後面的通訊。
所以說，目前的WebSocket不能完全脫離HTTP協議。不過，也很好公升級，只要確定雙方都支援WebSocket的話，直接跳過前期基於HTTP的握手即可。
在日常工程使用中，用WebSocket取代HTTP（握手還使用HTTP）已經是很普遍的了。避免了很多輪詢（包括長輪詢、短輪詢），提公升了系統的效能。
5樓：王mike
很多回答看的我一愣一愣的，題主的問題在深化一下，這不就是現代rpc麼，grpc，thrift等不就是幹這個的麼，還有扯長鏈結的，2023年了，epoll還沒普及麼，還是阿帕奇麼？看樣子http2任重而道遠啊
6樓：白添宇
你的這種假設是完全可能的，行得通，只是沒有必要。關鍵看客戶端與伺服器端的互動是否很頻繁。
一方面，http作為短連線，可以讓客戶端在空閒時讓出伺服器資源。另一方面，controller實現了完善的路由、攔截、過濾等功能。
所以，如果你的業務是訪問不夠頻繁，而且會用到web相關的功能，就沒必要用websocket，相比之下controller更適合。
7樓：yoom
可以。方案是可行的，最大的障礙是伺服器效能。如果是單頁面，並能確保使用者不太可能多開視窗。效能尚可接受，如果使用者可能開啟多個tab，由於瀏覽器tab間不能復用socket，所以對伺服器壓力會比較大。
8樓：
可以的。但是需要一些額外的工作。比如客戶端突然掉線、伺服器丟擲異常等等，類似http中的200、404、500等狀態碼。
考慮到客戶端可能使用不同的瀏覽器，有些瀏覽器不支援ws，所以不建議這麼做。
如果是服務之間的通訊，ws完全可以，主流的微服務框架都很多支援ws協議。除了ws以外，還有很多不同的通訊協議可供選擇。
9樓：小小萬能表
實際上，不建議這麼做，websocket更多用在雙工通訊以及對實時新要求非常強的應用，ajax擁有更好的相容性，通常情況下效能和穩定性更好，沒有特殊原因不建議換
10樓：暗滅
當然可以啊，我在八年前就這麼幹了。
實際完全可以拋棄Ajax，我自定義了一套語法，參考了知識庫裡常用的方式，主謂賓結構，客戶端發請求，誰，做什麼，目標，附加資訊，這乙個四元組就搞定了。
伺服器端的回應可以是Json。
伺服器端主動推，也可以，也是這種結構。
客戶端自定義乙個Dispatch，解析不同的事件，交給不同的方法去處理（這裡應該抽像出來類似於Controller的東西，參考Spring MVC）。
效果槓槓的。有興趣請看 game.ptteng.com (可惜當時沒完全理解AngularJS，導致Jquery和AngularJS1寫在一起了)。
遊戲裡的多數都是用WEBSocket完成的，後端其實也應該同樣抽像出來Controller，用來響應Websocket的Dispatch的請求。
11樓：Jim Liu
唔，我其實YY過一種完全基於WebSocket的架構，檢視不負責任何邏輯。注意是任何邏輯，只負責渲染。
所有資料通過WebSocket下發，所有事件通過WebSocket上報，在服務端處理完事件，把修改下發，更新檢視。
當我想好以後準備開始做DEMO，然後我覺得這個肯定已經有實現過了，果然M$的ASP.NET Core Blazor hosting models其實就類似……
然後我覺得自己很蛋疼就沒有繼續下去
12樓：易拉罐兒
單純看問題，不看問題描述的話，這個是沒有問題的，我之前參與的乙個專案，就是這樣做的。
但是並不一定適合所有專案的應用場景。可以分析一下Websocket的優勢劣勢來綜合判斷。
WebSocket特徵第乙個就是雙工通訊，而傳統意義上http的那種請求響應模式必須是由客戶端來不斷的req觸發服務端的response.無法做到服務端主動推送，當然不排除輪詢等奇淫技巧。。。
第二個就是再通訊的通道建立之後，每次的客戶端服務端通訊就不需要在重新建立通訊通道，所謂建立鏈結的代價可以減少很多，基於http的請求響應的模式底層還是在tcp之上的，每次請求都是需要付出這些代價的。
第三個Websocket保持所謂長連線，是需要耗費伺服器資源的，而基於http的模式客戶端與服務端在沒有通訊的情況下，服務端不需要關於連線維護的資源。
通過這三點，我們來分析一下，什麼情況下適合使用這種模式，首先針對第一點，如果你的系統對實時通訊的要求低或者沒有，也沒有需要服務端主動與客戶端發起動作的請求，則可以不使用或者，不必要使用websocket,有上述需求的使用websocket則會更加的方便開發。對於第二點如果系統服務端與客戶端互動密集，使用websocket也更加節省頻寬，通訊的效率更高，反之則差異不明顯，另外在網路環境不好的情況下，頻繁的重建連線也會消耗伺服器的效能。對於第三點如果系統客戶端比較少，例如只有幾百個甚至再多乙個數量級，一般的伺服器應該還是能拿的下的但是對於更大型的系統，每台服務如果都用websocket的話，會導致伺服器利用率下降。
因此綜上所述，在乙個網路環境比較好，客戶端相對不多的，。舉一些例子，比如醫院的內部業務系統，聊天應用等。
13樓：吳浩亮
感覺題目和問題描述說的不是一回事兒哦。
如果光說你描述中的問題的話，你的做法完全是可行的，只不過 websocket 屬於長連線，除了介面本身，還需要考慮其他因素，比如建立和維護這些長連線所消耗的伺服器資源。
剛好我前段時間也正好做過乙個基於 websocket 的虛擬貨幣交易所專案，因為交易所肯定是要有 K 線、OrderBook 等元件的，應該與你所描述的專案在實現層大同小異。
這個專案中，websocket 除了承擔實時資料的推送功能外，同時也模擬 http 中傳統的 request/response 模式來互動資料。但是專案中並沒有建立多個 websocket 鏈結，而是制定了一套比較完善的訊息協議。
所以你這裡需要的並不是多個 websocket 鏈結，而是一套推送資料的協議，每個頁面只訂閱某個與之相關聯 topic 的 channel，之後服務端只推送與當前 topic 相關的資料 ，或者傳送一次性請求（類似 request/response）。
最後再說下問題中對 websocket 和 controller 這兩個概念進行對比的一些看法，我感覺 controller 這個概念與 websocket 本身完全掛不上鉤，因為它是程式設計正規化中的概念，比如 MVC，而 websocket 僅僅是網路應用層的一種傳輸協議罷了。
14樓：
可以做，但是要分場合。由於你介紹的情況沒有什麼詳情，我暫時從我的個人角度分析下你們目前的做法和你設想的做法利弊各是什麼。
先說你當前的做法，你當前的做法相當於一次將客戶端的資料統統灌注到了客戶端，然後客戶端就快取此資料後，組裝各個頁面。這樣做的好處是減少了後期伺服器端的併發壓力，並且使用者切換頁面由於不用客戶端發起網路請求，故不會出現卡頓的情況，使用者體驗非常好。同時，由於只需要在一處把所有邏輯實現，開發更加簡單，開發速度也會更快。
但是這樣做的缺點是，由於所有資料都是一次性返回，單次資料量很大，當客戶端使用人數過多，並且可能同時申請頁面資料時，就可能導致使用者共同卡在同乙個申請資料的那個頁面上，出現無法做後續操作的可能。同時，由於申請頁面資料併發過多，可能導致伺服器同乙個服務介面出現過載，從而讓伺服器應用崩潰。
再說下你預想的做法，你預想的做法正好優缺點和當前你們的做法反過來，優點是將伺服器接受請求的壓力分散在不同的介面上，不會過於集中在乙個服務，故將來可以很好地做成集群，分開接受不同的功能請求。缺點是，客戶端每次切換頁面，都需要發起一次網路呼叫，使用者體驗度不如一次性載入所有資料的方法順暢。
總的來說，採用什麼方法都有自己的優缺點，要根據應用的服務人群，傳輸的資料量等實際情況來決定使用什麼辦法。從你的描述，統一乙個服務，集中式管理，就很容易在乙個地方把邏輯集中實現，開發速度上比分散的ws服務快很多，優先開發出產品並上線是實際生產上快速迭代產品的優選方法。等以後使用者量大了，可以考慮你設計的方法，做成分布式，減輕伺服器壓力。
15樓：lhrbu
你要的東西net core裡已經有了，blazor server-side模型，所有渲染都通過websocket提交給伺服器計算，之後diff返回給瀏覽器
16樓：木香丘
相容性、耗資源、重連線等等問題，其他回答已經很清楚了，不再贅述。使用 ws 來代替 Controller 要看場景。
基於 WS 實現類似 Controller 的通訊協議，其實已經存在很久了，它叫 JSON PRC，感興趣的可以了解一下。
前端與後端基於 WS 通訊，前端使用 RPC 風格呼叫後端的介面，後端也是用 RPC 風格呼叫前端介面。
典型的場景是：WebIDE 場景：
比如 vscode、eclipse theia ide 等等就是使用 JSON RPC 的方式通訊【也有小部分不是】。
為什麼 WebIDE 場景適合使用基於 WS 的 JSON RPC 通訊協議呢？
我個人認為主要有以下兩點考慮：
需要雙向通訊的能力【前端通過 RPC 呼叫後端介面，後端也可以通過 RPC 呼叫前端介面】
前後端通訊特別頻繁【相比 http，復用乙個 WS 連線情況下，頻繁地交換資料效能會更好，資源占用會更少】
所以，符合以上兩點，我認為是適合使用基於 WS 的 JSON RPC 通訊協議的。
你們可能會問能不能使用基於 HTTP 的 JSON RPC 通訊協議呢？
答案是可以的，我在這塊有一些實踐，驗證是可行的。
所以，我認為基於 HTTP 的 JSON RPC 是可以替代使用 Controller 來實現介面的這部分能力，但是像 ssr 這種場景就不太合適了。
基於 HTTP 的 JSON RPC 相較 MVC 的好處：
前端可以像呼叫本地方法一樣呼叫後端的介面
後端在實現介面的時候，不需要考慮介面的路由對映
我最近寫了乙個框架，就是基於 HTTP 的 JSON RPC 通訊：https://
agu。當然，這個框架也支援 MVC 協議，開發者可以根據自己的喜好選擇。感興趣可以參考一下。
假如我們要實現這樣乙個功能：前端呼叫後端介面。步驟如下：
首先定義好介面
2. 後端實現這個介面
3. 前端像呼叫本地方法一樣呼叫後端介面
如果妻子承擔家庭的主要經濟責任，能否要求丈夫承擔大部分家務
驢偉 妻子不承擔經濟責任也可以要求丈夫承擔家務。問題在於對方會不會欣然同意，怎麼才能讓對方欣然同意。這需要用智慧型，而不是強制和討價還價。 惡少惡言 這事兒得每家的老公老婆自己商量，而不是上知乎問能否要求。知乎都說能老公不同意咋辦？那個不承擔主要經濟責任的人，未必是幹家務幹的比較好的那個人，家務活這...
Python在資料科學領域能否完全取代R？
llanglli 不會，各有所長，雖然近年 python copy 並進一步強化了 R 的一些長處，例如 ggplot，但除了發揚光大的 pandas，並沒有形成很好的生態，相反，R 在效能瓶頸 視覺化 動態文件等方面一騎絕塵。貼一篇一年多前的舊文，基本論點仍然管用。llanglli 在這個人人擁抱...
能否將社會中的剝削完全消除？
永遠炙熱 資產階級生存和統治的根本條件就是資本的形成和增殖，而資本的條件是雇傭勞動，剝削是目的。說到剝削必然說到僱傭 私有制等等，私有制是要消滅的，它必將被更高階的所有制形式所代替，但那是乙個漫長的歷史過程。在向共產主義過渡的社會主義初級階段，也還不能消滅私有，制因為生產力還不夠發達。等到生產關係一...