24 | 跨平台与 Web 开发的建议

Jul 12, 2019

24 | 跨平台与 Web 开发的建议-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

24 | 跨平台与 Web 开发的建议

2019-07-12 许式伟来自北京

《许式伟的架构课》

课程介绍



讲述：丁伟

时长08:51大小8.11M



你好，我是七牛云许式伟。
上一讲我们聊了浏览器，以及移动浏览器之争：小程序与 PWA。
当我们思考浏览器从技术上带来了什么的时候，我们可以把它分为两点。
跨平台桌面程序开发；
Web 开发（B/S 架构的新型应用）。
今天我们分别就跨平台桌面程序和 Web 开发展开来聊一聊。
跨平台桌面程序开发跨平台的桌面程序开发是一个超级难题。无数人前仆后继，各种方案层出不穷，但至今为止，仍然没有称得上真正深入人心的解决方案。
原因很简单，因为桌面程序本身的范畴在变。有两个关键的因素会导致桌面开发产生巨大的差异性。
一个因素自然是操作系统。不同的操作系统抽象的界面程序框架并不一致。这些不一致必然导致开发工作量的增加。
放弃某个操作系统，就意味着放弃某个流量入口，也就意味着放弃这些用户。所以虽然很麻烦，我们还是不得不支持着每一个主流的操作系统。
另一个因素是屏幕尺寸。就算相同的操作系统，在不同尺寸的屏幕上，交互的范式也会存在很大的差异性，这也会导致不低的跨平台工作量。
首先我们看下操作系统。
PC 本地：Windows，macOS，Linux 等等；
PC Web：Chrome，Safari，FireFox 等等；
Mobile 本地：Android，iOS 等等；
Mobile Web：小程序，PWA 等等。
我们再看下屏幕尺寸。
大屏：PC、笔记本，Pad 等等；
中屏：手机；
小屏：手表。
如此繁复多样的终端类型，无怪跨平台如此之难。我们来总结一下当前都有哪些跨平台的解决方案。
这个列表只是沧海一粟。之所以没有列那么多，也是因为大部分的跨平台框架都已经不怎么活跃，已经无疾而终了。
目前来说，还很难说哪个方案会胜出。
关于跨平台开发，我觉得有一句话特别深刻：“每一次统一的努力，都最终变成新的分裂”。当然，这样的事情在很多领域都会发生，只是跨平台开发更加如此。
但是无论如何，跨平台的梦还会继续。
Web 开发聊完了跨平台，我们来聊聊浏览器带来的另一面：Web 开发。
Web 的 B/S 架构意味着编写软件有了更高的复杂性。这主要表现在以下几个方面。
其一，多用户。有了 Server 端，意味着用户的数据不再是保存在 Client（Browser）端，而是存储在 Server 端。
其二，更高的数据可靠性要求。数据在 Client 端，客户自己对数据的可靠性负责。硬盘坏了，数据丢了，用户会后悔没有对数据进行备份。
但是一旦数据在 Server 端，数据可靠性的责任方就到了软件厂商这边。如果厂商不小心把数据搞丢了，用户就会跳起来。
其三，更多可能的分工安排。详细来说，Web 应用从流派来说，分为两大类：胖前端与胖后端。
所谓胖前端，是指把尽可能多的业务逻辑放在前端。极端情况下，整个网站就是一个单页的应用。胖前端无论开发体验还是用户体验，都更接近于本地应用（Native App）。
所谓胖后端，是指主要逻辑都在后端，包括界面交互的事件响应，也通过网络调用交给了后端来实现。
我们先看客户端（Client），也就是浏览器端（Browser）。上一讲我们提到，浏览器的界面框架并没有窗口系统，它通过 HTML+CSS 来描述界面。
HTML+CSS 与其理解为 View 层，不如理解为 ViewModel 层，因为 HTML DOM 从数据角度完整描述了界面的样子。而 View 层已经被浏览器自己实现了。
这极大简化了界面开发的复杂性，因为界面的局部更新是一个复杂的话题，今天浏览器通过引入 HTML+CSS 这样的 ViewModel 层把它解决了。
这个时候我们重新看 MVC 框架在浏览器下的样子，你会发现它变成了 MVMP 模式，全称为 “Model-ViewModel-Presenter”。
首先，我们看事件响应过程。浏览器的 View 收到了用户的交互事件，它把这些事件委托（delegate）给了 ViewModel 层，并且通过 HTML DOM 暴露出来。通过修改 HTML 元素的事件响应属性，一般名字叫 onXXX（比如 onclick），可以获得事件的响应机会。
然后我们看 Model 层的数据变化（DataChanged）事件。在标准的 MVC 模式中，Model 层的数据变化是通知到 View 层，但是在浏览器下 View 是由浏览器实现的，要想让它接受 DataChanged 事件并且去处理是不太可能了。
所以解决思路自然是让 Controlller 层来做，这样就变成了 MVP 模式。 但是我们又不是标准的 MVP，因为 Presenter 层更新界面（Update View）并不是操作 View，而是 ViewModel。
综上，浏览器下的 MVC，最终实际上是 MVMP（Model-ViewModel-Presenter）。
聊完了浏览器端，我们在来看下服务端（Server）。虽然这一章我们的重点不是聊服务端，但是为了有个完整的认识，我们还是要概要地梳理一下 Server 端的架构。
前面我们在 “22 | 桌面程序的架构建议” 中，曾提到桌面软件除了要支持用户交互外，另一个很重要的需求是提供应用程序的二次开发接口（API）。
到了 Web 开发，我们同样需要二次开发接口，只不过这个二次开发接口不再是在 Client 端完成的，而是在 Server 端完成。Server 端支持直接的 API 调用，以支持自动化（Automation）方面的需求。
所以，对 Server 端来说，最底层的是一个多租户的 Model 层（Multi-User Model），它实现了自动化（Automation）所需的 API。
在 Multi-User Model 层之上，有一个 Web 层。Web 层和 Model 层的假设不同，Web 层是基于会话的（Session-based），因为它负责用户的接入，每个用户登录后，会形成一个个会话（Session）。
如果我们对 Web 层细究的话，又分为 Model 层和 ViewModel 层。为了区分，Web 这边的 Model 层我们叫它 Session-based Model。相应地，ViewModel 层我们叫它 Session-based ViewModel。
在服务端，Session-based Model 和 Session-based ViewModel 并不发生直接关联，它们通过自己网络遥控浏览器这一侧的 Model 和 ViewModel，从而响应用户的交互。
Session-based Model 是什么样的呢？它其实是 Multi-User Model 层的转译。把多租户的 API 转译成单租户的场景。所以这一层并不需要太多的代码，甚至理论上自动实现也是有可能的。
Session-based ViewModel 是一些 HTML+JavaScript+CSS 文件。它是真正的 Web 业务入口。它通过互联网把自己的数据返回给浏览器，浏览器基于 ViewModel 渲染出 View，这样整个系统就运转起来了。
结语今天我们聊了 Web 带来的两个重要改变。一个是跨平台，一个是 Web 开发，即 B/S 架构下的新型应用到底应该怎么实现。
从跨平台来说，这个话题是桌面程序员（也叫“大前端”）永远的痛。计划赶不上变化，用来形容大前端程序员面临的窘境是一点都不过分的。一个玩意还没搞熟悉了，另一个东西又出来了，变化太快，要跟上实属不易。
从 Web 开发来说，MVC 变成了 MVMP（Model-ViewModel-Presenter）。我们和单机的桌面软件一样的建议，认真对待 Model 层，认真思考它的使用接口是什么样的，把 Model 层做厚。
如果你对今天的内容有什么思考与解读，欢迎给我留言，我们一起讨论。下一讲我们将结合一个实际的案例，来讲解一下桌面开发（含单机软件和 Web）到底是什么样的。
如果你觉得有所收获，也欢迎把文章分享给你的朋友。感谢你的收听，我们下期再见。

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 9

提建议

23 | Web开发：浏览器、小程序与PWA

25 | 桌面开发的未来

 写留言

精选留言(22)

lckfa李钊
2019-07-13
因为工作的原因，莫名其妙的成为了大前端的一员，从Windows原生直绘界面到基于Qt的Web混合开发，再到Flutter移动跨平台，一路走来是越来越惊讶，前端的知识体系气泡越吹越大，突发学海无涯之感。不过我也一直在思考那么不变的东西，从框架的架构角度理解，它们其实是借鉴和传承的，因此不论是使用C++还是JS或者Dart，貌似都不再是难题了。学习架构课不一定就是奔着学完做架构师去的，也是为了更好的把自己的知识体系串通组建起来，没必要在开发语言的细节泥潭里无法自拔
展开
作者回复: 👍
共 3 条评论
42
笛神
2019-07-16
关于model层，一直认为使用spring框架的开发人员把service+dao用的太狭隘了，service堆满了业务处理，定义各种方法，感觉完全变回面向过程编程，丢掉了业务实体类，丢掉了数据行为封装，存在很多的耦合和重复。。一直想灌输将行为封装回业务实体里，service驱动业务实体来实现业务，而不是把所有业务逻辑在service层来实现掉。这样model层才会丰满，才是对现实世界的抽象，不知这个理解是否正确？
作者回复: 是这样
共 5 条评论
20
秋天
2019-07-16
model和viewmodel的本质区别是什么？老师
作者回复: model是业务数据，viewmodel是界面数据。因为界面体现业务，所以viewmodel和model的数据是有对应关系的，只不过数据结构不同
共 3 条评论
16
黄强
2019-07-12
认真对待Model层，将其做厚，相应的前端会更薄，更能适应变化的可能，再次体现架构师对稳定点，变化点的抉择
作者回复: 是的，本质就是这样
共 2 条评论
14
杨洪林
2019-07-12
server 架构下的automation 具体指那些动作？
作者回复: 这个是指外部系统对我们业务的api请求。我们的业务提供可视化的界面提供只是一种可能性，更重要的其实是如何让更多人使用我们的核心业务。
7
ANYI
2019-07-15
“”Model 层做厚”，老师，这个应该怎样去理解处理，很多现在项目都固化了，model就是对应了数据库表，通过service来处理业务，就是spring mvc这种分层，怎样去把这个model做厚呢？
作者回复: 我理解spring中把model分成了service+DAO，然后很多人认为model=DAO
共 2 条评论
3
Linuxer
2019-07-12
理解起来还是有些吃力，请问能结合一下具体项目吗？最好是某个开源项目
作者回复: 开源项目可能过大，我下一讲是打算做一个小例子
3
小鬼
2020-06-30
现在再回想起来，看看许老师以前在WPS的架构设计，其实沿用了很多年，包括后来我们在移动端还有Web端重新实现一遍，包括层次划分和模型，基本还是复用PC那套。从这个角度来看，做厚Model的价值就体现出来了，在不同平台上，Model是稳定的，可以快速展开工作，换种开发语言和平台，也只是再结合平台的特性去处理细节。
2
不温暖啊不纯良
2021-04-10
是不是mvc的设计思想，在前后端都有应用。前端的mvmc中的model指的是将用户行为产生的数据抽象成业务数据，比如说表单的填写就是，提前给用户设计好了业务模型，然后用户将数据输入这个模型，viewModel负责窗口的渲染,presenter是负责数据的存取。后端的mvc中的model指的是实体类，实体类是对业务的封装和模型化……只能编到这里了，重新理解一下，原来的桌面应用开发，在以前还没有前后端分离这一说，所以mvc应该涵盖整个开发流流程……哦，我明白了，整个mvc应该是从业务架构的角度出发去理解它，那么任何应用的架构都是从业务需求开始的，有了业务需求之后，第1个产生的应该就是业务模型，也就是model层，m排第一，然后是我们必须要把业务数据和代码可视化，于是有了view 层，让用户在特定的业务框架中去交互，实行业务操作，生产业务数据，最后把用户这些数据处理和存储，也就是我们的controller 层。原来mvc架构思想，是对需求的一种抽象的模板。好了老师，我编完了。
展开
作者回复: 后端不需要mvc，后端整体就是一个多租户的m
共 2 条评论
2
J.Smile
2020-01-08
老师真全能
1
剑八
2019-08-02
浏览器解决跨操作系统问题本质上要求其它系统服务对外提供一套标准未来云也会有一套标准，云上的中间件会基于这个标准构建
1
Eternal
2019-07-29
被MVC，MVP，MVMP绕晕了
作者回复: 名词其实不重要，重要的是逻辑。我背后想说的意思其实是，这些一堆堆的模式，本质上是同一个模式，只是一些细节选择上不同形成的变种。这些细节差异并不那么重要。
2
有只骆驼
2019-07-15
还是有点迷糊。在过去的实际开发中，我们对于Model 层的讨论经常在探讨到底是贫血模型还是充血模型。从某种意义上来说，Model 除了不仅不是一层薄薄的的数据载体和简单的行为定义外，还承载着对整个业务对象描述与驱动，概括了业务核心的本身且能被任意需要的合法对象消费。感觉自从上次GIAC大会后，大佬们都在说领域驱动设计所想表达的思想。
展开
作者回复: 是这样，这个和giac没啥关系
1
木瓜777
2019-07-13
您好，对model层的理解还是不够，我原先最早认为就是数据结构层，您说把model层做厚的含义是什么？
作者回复: 业务逻辑层，也是整个系统的核心
共 3 条评论
1
1900
2019-07-12
为啥桌面程序员也叫大前端呢？（另外到底啥叫大前端呢？）我的初步理解是和用户打交道的软件开发叫前端开发，我的理解对么？最后，有“大后端”这个术语么？如果有，具体又指什么？
作者回复: 是的，和用户打交道都是前端或桌面（感觉前端可能更好一些）。叫大前端我理解主要为了强调前端的广度，因为操作系统实在太多了。
共 2 条评论
1
虎哥
2019-07-12
把多租户的 API 转译成单租户的场景。所以这一层并不需要太多的代码，甚至理论上自动实现也是有可能的。请问哪里有相关资料可以查阅这个内容
作者回复: 下一讲是一个例子
1
卢
2021-10-11
许老师，你好！文中把model层做厚该怎么理解？利用数据库存储过程简化代码逻辑？设计更优的数据结构？没理解做厚是啥意思
作者回复: 就是提炼符合业务语义的api层，而不是让js离数据库操作太近（不封装带业务语义的api）。
Geek_88604f
2020-08-05
Session-based Model 和浏览器一侧的 Model是怎么交互的，没太明白。
作者回复: 通过网络协议，一端是seever，一端是client
Lukia
2020-05-16
“在服务端，Session-based Model 和 Session-based ViewModel 并不发生直接关联，它们通过自己网络遥控浏览器这一侧的 Model 和 ViewModel，从而响应用户的交互。”关于这一点有几个问题请教老师。1. 为什么在服务端和浏览器分别都会有mode和view model层 2.如果说viewmodel是考虑到表现，对model层的转译，那么model是不是应该在服务端同时view model在浏览器端呢 3.
共 1 条评论
大头爸爸
2020-04-25
”但是一旦数据在 Server 端，数据可靠性的责任方就到了软件厂商这边。如果厂商不小心把数据搞丢了，用户就会跳起来。“ 请问这里的软件厂商是浏览器这边还是服务器这边?
作者回复: 服务端

