離開了園子很久很久了 疫情期間,沒有辦法出差,正好當前時間是自己規劃的查漏補缺時間,把缺少的Web模塊的統計分析圖表加進去 Webassembly 老早是聽說了,但由於項目的原因,也一直沒有精力去關註,倒是 netcore3.1期待了很久,雖然最後測試了一下,自己需要的核心介面還沒有添加進去,但是W ...
離開了園子很久很久了
疫情期間,沒有辦法出差,正好當前時間是自己規劃的查漏補缺時間,把缺少的Web模塊的統計分析圖表加進去
Webassembly 老早是聽說了,但由於項目的原因,也一直沒有精力去關註,倒是 netcore3.1期待了很久,雖然最後測試了一下,自己需要的核心介面還沒有添加進去,但是Webassembly 與 Blazor 還是給我帶來了驚喜。
1、Webassembly 實現了 netstandard 的介面。我的業務邏輯層的實體類dll,可以不作任何修改,直接應用於Browser的Webassembly。去年基於tekerik的KendoUI差不多整了個前端的應用框架,但是需要定義傳輸實體類,雖然可以通過工具生成js,綁定、查詢、提交之類,但是畢竟要重新生成,修改了一個地方,js也要跟著修改,工作量還是非常大的,js與C#畢竟還是有很大的差異,人的培訓又是個很大的問題。有了webassembly 後,dll可以直接使用,不需要生成一大堆的js,代碼量與工作量直線下降,後端人員可以寫前端了。可能從效果上來說,還達不到js的展現之類,由於我們的軟體是應用於企業內部,優點是大大超越不足。
2、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。

@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; } } }View Code
大家看看這個調用方式,與寫普通的遠程調用有什麼差異嗎?完全沒有。這也是RPC給我帶來的驚喜中的驚喜,在browser可以直接調用後臺服務。
再看看後臺的服務代碼。

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; }View Code
3、Blazor 應該說是為了實現webassembly而打造了,有了webassembly和RPC,加了Blazor的雙向綁定,app與desktop 的做法,在web上面,可以差不多用一樣的風格實現了,至少對於業務系統可以是這樣。
由於在測試的時候CORS出現了一些問題,需要等上一些時間再把Demo傳上來