離開了園子很久很久了
疫情期間，沒有辦法出差，正好當前時間是自己規劃的查漏補缺時間，把缺少的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傳上來
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/1053.html
標籤：領域驅動設計