纤凝-基于鸿蒙的设计开发模式的讨论 原创 精华
Time: 28 January,2022
Author: Hairtail
Location: Gao Xing
一、它山之石可以攻玉
1.木棉花小蓝：【木棉花】知识分享——Ability的介绍
此文详细介绍了三大Ability的特征，最后根据这些特征类别成MVC模式。（当然也介绍了MVC模式）
2.唐佐林老师在【木棉花】知识分享——Ability的介绍 的评论：
唐佐林老师对鸿蒙设计开发模式更偏向于MVP模式
3.OpenHarmony开源开发者成长计划-知识赋能第二期-梁皓老师
在OpenHarmony开源开发者成长计划-知识赋能第二期第一次课程中，提到不管是HarmonyOS还是OpenHarmony的基于JS扩展的类Web开发范式和基于TS扩展的声明式开发范式的开发的核心思想是MVVM，核心思想是数据驱动视图和双向数据绑定。
4.Web前端框架技术综述-郭蕊,赵元苏
引用：[1]郭蕊,赵元苏.Web前端框架技术综述[J].北京工业职业技术学院学报,2021,20(03):24-27.
鉴于是论文，大家可以下载下来看看，应该会很有帮助！
1.详解了MVC，MVP，MVVM三个模式
2.详解了Vue、Angular、React三个框架
**1.**MVC( Model View Controller)框架模式即为模型( Model)、视图( View)和控制器(Controller)的分层模式。模型层用于处理数据的部分,能够直接针对相关数据进行访问,针对应用程序业务逻辑的相关数据进行封装处理;视图层能够显示网页,由于视图层没有程序逻辑,因此需要对数据模型进行监视和访问;控制层主要体现在对应用程序流程的控制，以及对事件的处理和响应上。控制层能够获取用户事件信息,通知模型层进行更新处理,由模型层将处理结果发送给视图层,视图层的相关显示信息随之发生改变,因此控制层对于视图层以及模型层的一致性进行了有效的调节和控制。
**2.**MVP模式：其中, Mod-el提供数据，View 负责显示, Presenter负责逻辑的处理,其通过接口与 View通信的界面逻辑组件。在MVP模式中,首先, View 与Model完全隔离,使得模型层的业务逻辑具备了较好的灵活性。其次, Pres-enter 与 View的具体实现无关,应用可以在同一个模型层适配多种技术并构建视图层。同时,由于View和Model没有直接关系,因此 MVP模式可以进行View 的模拟测试。
**3.**MVVM ( Model View ViewModel)为Model(模型) - View(视图) 一 ViewModel(视图模型)框架模式。MVVM模式的出现是为了解决MVP模式中，由于UI种类变化频繁导致接口不断增加的问题。其设计思想是“数据驱动界面”,以数据为核心,使视图处于从属地位。
- 该模式只需要声明视图和模型的对应关系,数据绑定由视图模型完成,相当于MVC模式的控制器,实现了视图和模型之间的自动同步。
- MVVM模式简化了MVC和MVP模式,不仅解决了MVC和MVP模式中存在的数据频繁更新的问题,同时使界面与业务之间的依赖程度降低。在该模式中,视图模型、模型和视图彼此独立,视图察觉不到模型的存在。
- 优势：低耦合、可重用性、独立开发、可测试性
二、终有所悟
关于MVVM，这个思想在Vue、Angular框架都得到了贯彻。且修改了数据，HarmonyOS与OpenHarmony自动会重新渲染。根据梁皓老师的直播演示和讲解，我比较同意梁皓老师的观点。
即：Harmony与OpenHarmony的设计开发模式均为MVVM
手动@木棉花小蓝和唐佐林老师~
从目前暴露的接口和整体开发方式来看也许更接近 MVVM，但是我觉得 HarmonyOS 的框架设计不会是瞄准了 MVVM 进行的，应该还是为了尽力满足更多类型的应用，并且 MVVM 和 MVP 并无冲突性的差异，就看应用需要了。
从开发角度，多数的应用 case 还是偏向于 MVP ，数据强双向绑定的 case 貌似不多。
比如：
1. 购物应用，Cloud -> DataAbility -> Presenter -> View
2. 视觉应用，1) Camera -> Presenter -> View 2) View -> Presenter -> Storage
感谢老师解惑！~
阔以肯定是使用基于JS扩展的类Web开发范式的方舟开发框架肯定是MVVM模式，同样的eTS也是数据驱动视图。在HarmonyOS文档和OpenHarmony文档均有对比图。
HarmonyOS文档：
OpenHarmony文档：
所以到底是类似哪种模式，我已经晕了