22 | 桌面程序的架构建议

这几种模式中，对 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 的双向绑定。

许老师好！ 工作中也经常用到MVC模式开发，经常用个Mode层就是一个和数据库映射的实体，然后再View层和Controller层传输数据，不知道老师文中所指的Mode层应该是“负责需求的内核逻辑”应该如何理解？难道需求的逻辑不是应该放到Controller里的Services里去实现吗？

不同视角看待架构的最终方向都是一致的: 稳定点和扩展点分离，分而治之的思想 《clean code》书中的架构设计，最核心的是领域Model，它是稳定的。 《实现领域驱动设计》中的战略设计是分之思想，将核心问题域与其他问题域进行分离，划分出核心域，支撑域，通用域，最终的目的是将架构的核心需求进行确定。 架构设计中，clean code架构、四层架构、六边形架构、微服务架构无一例外。 许老师讲Model的时候，我想起了领域驱动设计中的领域模型，真是不谋而合呀。

比较抽象，许老师，有没有比较好的实例程序推荐，通过程序来理解应用架构的具体细节？

开始不理解了，需要多经历，然后再回头来看

“文档对象模型”中的“文档”应该如何理解？是因为linux中“一切皆文件”，所以这里一切皆文档么？ 我目前只能理解“对象”和“模型”，对象指数据+操作，数据对应了结构体（数据结构），操作对应了方法（方法的集合可以封装成接口）；模型本质上指的是抽象。 那“文档”该如何理解？

许老师可否展开讲一下如何把model 层做厚，感觉这一部分挺重要的

期待老许谈谈对DDD领域驱动设计的看法。

代理和委托到底是一种模式还是两种模式？

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