離開了園子好久好久了前端
疫情期間,沒有辦法出差,正好當前時間是本身規劃的查漏補缺時間,把缺乏的Web模塊的統計分析圖表加進去web
Webassembly 老早是據說了,但因爲項目的緣由,也一直沒有精力去關注,卻是 netcore3.1期待了好久,雖然最後測試了一下,本身須要的核心接口尚未添加進去,可是Webassembly 與 Blazor 仍是給我帶來了驚喜。json
一、Webassembly 實現了 netstandard 的接口。個人業務邏輯層的實體類dll,能夠不做任何修改,直接應用於Browser的Webassembly。去年基於tekerik的KendoUI差很少整了個前端的應用框架,可是須要定義傳輸實體類,雖然能夠經過工具生成js,綁定、查詢、提交之類,可是畢竟要從新生成,修改了一個地方,js也要跟着修改,工做量仍是很是大的,js與C#畢竟仍是有很大的差別,人的培訓又是個很大的問題。有了webassembly 後,dll能夠直接使用,不須要生成一大堆的js,代碼量與工做量直線降低,後端人員能夠寫前端了。可能從效果上來講,還達不到js的展示之類,因爲咱們的軟件是應用於企業內部,優勢是大大超越不足。後端
二、RPC!!!實現了webassembly的RPC,這個大概花了不到2周的時間進行移植與測試,與我當前用的後臺能夠無縫對接。我後臺的服務也能夠不做任何的修改,browser webassembly客戶端能夠直接以RPC方式調用,這更是驚喜中的驚喜呀。這樣,個人服務層經過asp.netcore公開出去後,xamarin app、browser、desktop能夠採用統一的服務接口。因爲原來主要的工做是在app和desktop程序上面,並且app與desktop使用了很是類似的代碼風格與樣式,統一的集中權限管理。webassembly blzaor 帶給咱們徹底一致的風格,統一了app、browser、desktop。咱們的RPC調用傳輸部分,用的是自行改版後的protobuf,已經用了不少年了,效率、穩定性都通過了N多項目的檢驗。曾經嘗試用protobuf.js,最終失敗,後來就一直放下了。若是不可以實現從browser直接調用服務,就要架個服務的中轉,把protobuf的調用再轉換成json。項目裏面,那麼多的接品,這個轉換,也是個非龐大的工做量,並且是專門用於web的,app與desktop 的RPC調用,仍是基於原來的protobuf。app
@page "/" @using Demo.Shared @using EES.Common <h1>Hello, world!</h1> Welcome to your new app. <p>Current: @value</p> @code { string value; protected override async Task OnInitializedAsync() { try { User user = await Factory.getProxy<HelloService>().getUserAsync("Say"); value = user.UserCode; } catch (Exception ex) { value = ex.Message; } } }
你們看看這個調用方式,與寫普通的遠程調用有什麼差別嗎?徹底沒有。這也是RPC給我帶來的驚喜中的驚喜,在browser能夠直接調用後臺服務。框架
再看看後臺的服務代碼。asp.net
public User getUser(string name) { User u = Factory.Create<User>(); u.Age = new Random().Next(0, 120); u.UserCode = string.Format("{0}-{1:yyyy-MM-dd HH:mm:ss.fff}", name, DateTime.Now); return u; }
三、Blazor 應該說是爲了實現webassembly而打造了,有了webassembly和RPC,加了Blazor的雙向綁定,app與desktop 的作法,在web上面,能夠差很少用同樣的風格實現了,至少對於業務系統能夠是這樣。dom
因爲在測試的時候CORS出現了一些問題,須要等上一些時間再把Demo傳上來async