软件设计：关于webassebmlyBlazorRPC调用

作者:光影传说更新于： 2020-04-09 22:20:17

　　RPC(RemoteProcedureCallProtocol)--远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

　　离开了园子很久很久了

　　疫情期间，没有办法出差，正好当前时间是自己规划的查漏补缺时间，把缺少的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周的时间进行移植与测试，与我当前用的后台可以无缝对接。我后台的服务也可以不作任何的修改，browserwebassembly客户端可以直接以RPC方式调用，这更是惊喜中的惊喜呀。这样，我的服务层通过asp.netcore公开出去后，xamarinapp、browser、desktop可以采用统一的服务接口。由于原来主要的工作是在app和desktop程序上面，而且app与desktop使用了非常相似的代码风格与样式，统一的集中权限管理。webassemblyblzaor带给我们完全一致的风格，统一了app、browser、desktop。我们的RPC调用传输部分，用的是自行改版后的protobuf，已经用了很多年了，效率、稳定性都经过了N多项目的检验。曾经尝试用protobuf.js，最终失败，后来就一直放下了。如果不能够实现从browser直接调用服务，就要架个服务的中转，把protobuf的调用再转换成json。项目里面，那么多的接品，这个转换，也是个非庞大的工作量，而且是专门用于web的，app与desktop的RPC调用，还是基于原来的protobuf。

　　@page"/"

　　@usingDemo.Shared

　　@usingEES.Common

Hello,world!

　　Welcometoyournewapp.

Current:@value

　　@code{

　　stringvalue;

　　protectedoverrideasyncTaskOnInitializedAsync()

　　{

　　try

　　{

　　Useruser=awaitFactory.getProxy().getUserAsync("Say");

　　value=user.UserCode;

　　}

　　catch(Exceptionex)

　　{

　　value=ex.Message;

　　}

　　}

　　}

　　大家看看这个调用方式，与写普通的远程调用有什么差异吗？完全没有。这也是RPC给我带来的惊喜中的惊喜，在browser可以直接调用后台服务。

　　再看看后台的服务代码。

　　publicUsergetUser(stringname)

　　{

　　Useru=Factory.Create();

　　u.Age=newRandom().Next(0,120);

　　u.UserCode=string.Format("{0}-{1:yyyy-MM-ddHH:mm:ss.fff}",name,DateTime.Now);

　　returnu;

　　}

　　3、Blazor应该说是为了实现webassembly而打造了，有了webassembly和RPC，加了Blazor的双向绑定，app与desktop的做法，在web上面，可以差不多用一样的风格实现了，至少对于业务系统可以是这样。

　　由于在测试的时候CORS出现了一些问题，需要等上一些时间再把Demo传上来

　　RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息的到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。