许式伟的架构课
许式伟
七牛云CEO
立即订阅
19913 人已学习
课程目录
已更新 71 讲 / 共 77 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 怎样成长为优秀的软件架构师?
免费
基础平台篇 (21讲)
01 | 架构设计的宏观视角
02 | 大厦基石:无生有,有生万物
03 | 汇编:编程语言的诞生
04 | 编程语言的进化
05 | 思考题解读:如何实现可自我迭代的计算机?
06 | 操作系统进场
07 | 软件运行机制及内存管理
08 | 操作系统内核与编程接口
09 | 外存管理与文件系统
10 | 输入和输出设备:交互的演进
11 | 多任务:进程、线程与协程
12 | 进程内协同:同步、互斥与通讯
13 | 进程间的同步互斥、资源共享与通讯
14 | IP 网络:连接世界的桥梁
15 | 可编程的互联网世界
16 | 安全管理:数字世界的守护
17 | 架构:需求分析 (上)
18 | 架构:需求分析 (下) · 实战案例
19 | 基础平台篇:回顾与总结
加餐 | 我看Facebook发币(上):区块链、比特币与Libra币
加餐 | 我看Facebook发币(下):深入浅出理解 Libra 币
桌面开发篇 (16讲)
20 | 桌面开发的宏观视角
21 | 图形界面程序的框架
22 | 桌面程序的架构建议
23 | Web开发:浏览器、小程序与PWA
24 | 跨平台与 Web 开发的建议
25 | 桌面开发的未来
26 | 实战(一):怎么设计一个“画图”程序?
27 | 实战(二):怎么设计一个“画图”程序?
28 | 实战(三):怎么设计一个“画图”程序?
29 | 实战(四):怎么设计一个“画图”程序?
30 | 实战(五):怎么设计一个“画图”程序?
31 | 辅助界面元素的架构设计
课外阅读 | 从《孙子兵法》看底层的自然法则
加餐 | 想当架构师,我需要成为“全才”吗?
32 | 架构:系统的概要设计
33 | 桌面开发篇:回顾与总结
服务端开发篇 (14讲)
34 | 服务端开发的宏观视角
35 | 流量调度与负载均衡
36 | 业务状态与存储中间件
37 | 键值存储与数据库
38 | 文件系统与对象存储
39 | 存储与缓存
40 | 服务端的业务架构建议
41 | 实战(一):“画图”程序后端实战
42 | 实战(二):“画图”程序后端实战
43 | 实战(三):“画图”程序后端实战
44 | 实战(四):“画图”程序后端实战
45 | 架构:怎么做详细设计?
46 | 服务端开发篇:回顾与总结
加餐 | 如何做HTTP服务的测试?
服务治理篇 (11讲)
47 | 服务治理的宏观视角
48 | 事务与工程:什么是工程师思维?
49 | 发布、升级与版本管理
50 | 日志、监控与报警
加餐 | 怎么保障发布的效率与质量?
51 | 故障域与故障预案
52 | 故障排查与根因分析
53 | 过载保护与容量规划
54 | 业务的可支持性与持续运营
55 | 云计算、容器革命与服务端的未来
56 | 服务治理篇:回顾与总结
架构思维篇 (8讲)
57 | 心性:架构师的修炼之道
用户故事 | 站在更高的视角看架构
58 | 如何判断架构设计的优劣?
59 | 少谈点框架,多谈点业务
60 | 架构分解:边界,不断重新审视边界
加餐 | 实战:“画图程序” 的整体架构
61 | 全局性功能的架构设计
62 | 重新认识开闭原则 (OCP)
许式伟的架构课
登录|注册

22 | 桌面程序的架构建议

许式伟 2019-07-05
你好,我是七牛云许式伟。
上一讲我们介绍了图形界面程序的框架。站在操作系统交互子系统的角度来看,我们桌面应用程序的结构是下面这样的。
今天我们换一个角度,站在应用架构的角度,来聊聊如何设计一个桌面应用程序。

从 MVC 说起

关于桌面程序,我想你听得最多的莫过于 MVC 这个架构范式。MVC 全称是 “模型 (Model)- 视图 (View)- 控制器 (Controller)”。
怎么理解 MVC 呢?一种理解是,Model 是 Input,View 是 Output,Controller 是 Process,认为 MVC 与计算机的 Input-Process-Ouput 这个基础模型暗合。
但更准确的解释是:Model 是数据,View 是数据的显示结果,同时也接受用户的交互动作,也就是事件。从这个意义来说,说 Model 是 Input 并不严谨,View 接受的用户交互,也是 Input 的一部分。
Controller 负责 Process(处理),它接受 “Model + 由 View 转发的事件” 作为 Input,处理的结果(Output)仍然是 Model,它更新了 Model 的数据。
View 之所以被理解为 Output,是因为 Model 的数据更新后,会发送 DataChanged(数据更新)事件,View 会在监听并收到 DataChanged 事件后,更新 View。所以把 View 理解为 Output 也并不算错,它从数据角度看其实是 Model 的镜像。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《许式伟的架构课》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(32)

  • Smallfly
    这几种模式中,对 MVVM 理解是最多样化的,很大一部分原因是取决于原来是如何使用 MVC 的,可以分为三种流派:

    1、在 Controller 中处理所有的业务逻辑,包括监听 View 事件, IO 请求数据,格式化 Model 数据供 View 展示等。该流派认为 ViewModel 是 Controller 的瘦身。

    2、在 Model 中处理大部分的业务逻辑,也就是所谓的“胖 Model”,Model 提供格式化的数据给 View,Model 就需要关心 View 的细节,导致 Model 的复用性变差。将格式化 Model 的数据转移到 ViewModel 中,认为 ViewModel 是胖 Model 的瘦身。

    3、最后一种,是老师文中说的,ViewModel 属于 View 的一部分,辅助 View 局部更新,我还是第一次听到这种说法。在我看来局部化更新由 Controller 来触发,ViewModel 只负责提供数据,完全跟 View 扯不上关系。但从 Word 的例子来看,这么说也有道理。不过老师也解释了,该模式并不算 MVVM。

    要理解一个名词真正的概念,需要追溯它的源头,MVVM 最早是由微软工程师 John Grossman 于 2005 年提出的。ViewModel 作为 View 的数据抽象层,持有 View 的状态和行为。

    ViewModel 和 View 不应该有引用关系,而是由中间者,将它们绑定。ViewModel 改变后自动的触发对应 View 的更新,View 的触发事件后,ViewModel 接收并做处理。在实现层面这种绑定关系最适合由响应式框架来做,从而实现 ViewModel 和 View 的双向绑定。

    作者回复: 挺好的补充

    2019-07-06
    2
    22
  • 被讨厌的勇气
    比较抽象,许老师,有没有比较好的实例程序推荐,通过程序来理解应用架构的具体细节?

    作者回复: 后面会考虑讲一个例子

    2019-07-05
    12
  • 唯一每天12点等更新的专栏
    2019-07-05
    9
  • 马哲富
    许老师好!
        工作中也经常用到MVC模式开发,经常用个Mode层就是一个和数据库映射的实体,然后再View层和Controller层传输数据,不知道老师文中所指的Mode层应该是“负责需求的内核逻辑”应该如何理解?难道需求的逻辑不是应该放到Controller里的Services里去实现吗?

    作者回复: 你说的service,应该就是我说的model层。一些说法是把model层分为service和DAO层,但是实际上DAO根本算不上一层。

    2019-07-05
    1
    6
  • Lrwin
    不同视角看待架构的最终方向都是一致的: 稳定点和扩展点分离,分而治之的思想



    《clean code》书中的架构设计,最核心的是领域Model,它是稳定的。

    《实现领域驱动设计》中的战略设计是分之思想,将核心问题域与其他问题域进行分离,划分出核心域,支撑域,通用域,最终的目的是将架构的核心需求进行确定。

    架构设计中,clean code架构、四层架构、六边形架构、微服务架构无一例外。



    许老师讲Model的时候,我想起了领域驱动设计中的领域模型,真是不谋而合呀。

    作者回复: 👍,挺好的补充

    2019-07-12
    1
    4
  • Smallfly
    关于文中 MVC、MVP 的理解,跟我原先理解的不太一样,查了一些英文资料,大概是这样:

    1、标准的 MVC,View 和 Model 是不能通信的,是由 Controller 监听 Model 的 DataChanged,然后去更新 View,而不像文中说的 View 直接监听 DataChanged。

    2、MVP 中 (UI)Controller 和 View 属于 V,P 接管了原先 MVC 中 Controller 处理协调 Model 和 View 的逻辑。
    2019-07-06
    4
  • 勇闯天涯
    经过许老师一番分析,对MVC的理解更深刻了,明天到公司把ViewModel重新捋捋。
    2019-07-05
    4
  • 小智e
    开始不理解了,需要多经历,然后再回头来看

    作者回复: 是的,这本书因为内容高度浓缩,需要反复看。这是练内功与练外功的区别。练外功可能有学完的那天,内功没法学完,甚至可能你会发现比书上更好的体悟。

    2019-07-06
    3
  • 1900
    “文档对象模型”中的“文档”应该如何理解?是因为linux中“一切皆文件”,所以这里一切皆文档么?

    我目前只能理解“对象”和“模型”,对象指数据+操作,数据对应了结构体(数据结构),操作对应了方法(方法的集合可以封装成接口);模型本质上指的是抽象。

    那“文档”该如何理解?

    作者回复: 这个是一个惯例,一般对象模型是一颗树,树根叫Document,所以叫DOM(文档对象模型)。xml的根对象就是Document是同样的道理。

    2019-07-05
    3
  • 靠人品去赢
    老师讲到了MVC和MVVM构架,我理解的前后端分离是一个趋势,model不单单是数据model,同样view也不单单只是用来展示。实际上要把control这个拆开,view也需要control,他可以是有向后台发送请求的,他同样也可以是只是简单的视图交互比如说弹一个对话框。model也是需要control,他可以接受前台请求进行逻辑判断处理数据返回结果,他同样就是跑一个任务,主动去推送不同的数据给用户。

    作者回复: 嗯,我这一讲还是单机软件,后面会谈b/s和c/s结构下的架构。

    2019-07-05
    3
  • 诗泽
    许老师可否展开讲一下如何把model 层做厚,感觉这一部分挺重要的

    作者回复: 假设总代码量不变,那其实就是尽可能把view和controller代码尽可能转model层

    2019-07-05
    3
  • Aaron Cheung
    打卡22 从来没有站在老师这样的高度看模型
    2019-07-05
    2
  • 有铭
    我是一个经历过MFC时代桌面程序的后端,今天文章提到一点,让我有所感触,就是前端的Model层尽量要厚重,按我的理解,这似乎有个专用名词称呼叫“充血模型”。这一点似乎和后端流行的想法是不太一样的,后端这10年,主要逻辑都集中到Controller和Service层了,Model层用的都是贫血模型。而这10年恰恰是后端去View化兴起的时代——只输出json,不输出页面。我有种奇怪的感觉,Model之所以要厚是因为要承载逻辑。从这个角度看,后端的Model不像Model,倒是Controller和Service承担了Model的职能,不知道各位怎么看这个问题

    作者回复: 后面会谈到b/s或c/s之后导致的变化

    2019-07-05
    3
    2
  • xwhsky
    光这节课就值回所有票价!
    2019-07-05
    1
    2
  • Geek_e55641
    按许老师的说法,mvc 跟mvvm 并不是一个可以互相替换的模型,vm 只是view 的一个部分的话,mvvm 模型里面怎么体现contoller 的逻辑呢?

    作者回复: 还是要有controller的,只是没画出来

    2019-07-05
    2
  • 黄强
    留言中有些人提到在controller层和model层增加一个service层,我是这样理解的:service(业务逻辑处理)+repository(DAO数据访问)+model(贫血模型)= Model层(数据层+业务逻辑);MVC只是一个架构的分层思想,在MVC各层同样可以用MVC分层的思想根据实际的需要再分层处理。
    2019-07-09
    1
    1
  • Barry
    我习惯在model层和controller层中间加一层service层。主要的数据处理都放在service层

    作者回复: 分层其实不是越多越好

    2019-07-09
    1
    1
  • 质量挺好
    2019-07-06
    1
  • Eason
    许老师的MVC,依我理解,Facebook 的React+Redux体现了不少。是不是以后章节也会谈到这些?

    作者回复: 会谈到一些

    2019-07-06
    1
  • Geek_88604f
    从分层角度,我们会倾向于认为 Model 层在最底层;View 层在中间,它持有 Model 层的 DOM 指针;Controller 层在最上方。这个分层方式有点不太理解,按我的想法view接收用户的输入它应该在最上方。麻烦许老师详细解释一下。

    作者回复: 从架构的层次,不是用户响应业务流程

    2019-07-06
    1
收起评论
32
返回
顶部