MVVM模式在嵌入式GUI AWTK 中的实现

AWTK-MVVM是一套为AWTK用C语言开发,并支持各种脚本语言的MVVM框架,实现了数据绑定、命令绑定和窗口导航等基本功能,使用AWTK-MVVM开发应用程序,无需学习AWTK本身的API,只需学习绑定规则和Model的实现方式即可。

1.1 分离用户界面和业务逻辑

在开发应用程序时,要把用户界面和业务逻辑分离开来,这是每个程序员都知道的常识。分离用户界面和业务逻辑有几个重要的好处:

  1. 有利于隔离变化。用户界面是最容易变化的,易用性的改进,外观的美化和需求的变化,首先冲击的就是用户界面。如果用户界面和业务逻辑耦合到一起,界面上一点微小的改动都会导致一系列代码的修改,这不但会增加开发的成本和周期,而且这种改进也是很无趣的,让程序员的幸福感直线下降。

  2. 有利于自动测试。代码中的BUG,越早被发现,修改的成本越低,而单元测试是在早期发现BUG的重要手段。单元测试是自动化的,前期编写测试代码的投入,会因为后期节省测试的时间而获得回报。单元测试代码可以不断积累,为软件构建一道坚固的防火墙,让整个系统越来越稳定。分离用户界面和业务逻辑是提高代码可测试性的重要手段,让编写单元测试程序成为可能。

  3. 有利于分工合作。用户界面和业务逻辑的耦合,会让用户界面的修改很困难,程序员就会抵触用户界面的改动,让设计师和程序员之间的矛盾加大。分离用户界面和业务逻辑后,设计师的工作成果可以平滑的输出给程序员,让程序员和设计师一起过上共同幸福的生活。

1.2 如何分离用户界面和业务逻辑

分离用户界面和业务逻辑,MVVM是目前最常用的模式。MVVM并非凭空出现,而是由MVC和MVP一路演化而来的,每次演化都是为了解决之前没有解决的问题。

1.2.1 MVC模式

MVC是Model-View-Controller简称,它首次把系统分成Model,View和Controller这三部分,明确的把用户界面和业务逻辑分离开来:

MVVM模式在嵌入式GUI AWTK 中的实现_第1张图片

  • 模型(Model)。简单的说,模型就是业务逻辑。我们经常说面向对象的设计和建模,所建立的模型就是这里的模型,是对现实世界中业务逻辑的抽象。面向对象的建模,就是要找到业务逻辑中有哪些类以及这些类之间的关系。类描述了对象的属性和行为,类是设计时的概念,对象是运行时的概念。对象通常就是业务实体,Model包含一个或多个业务实体。很多人(包括国内一些知名的专家)认为模型就是数据,这是没有透彻理解面向对象的设计导致的,对象是即有数据又有行为的,光有数据没有行为,就无法让对象之间协作,无法共同完成业务逻辑。

  • 视图(View)。这个是大家都知道的,就是用户与软件交互的界面,对于GUI应用程序来讲,就是窗口和对话框,以及上面的各种控件。视图应该说是为用户提供了一个界面,让用户可以观察和操作模型。

  • 控制器(Controller)。控制器负责解释来自用户通过键盘/鼠标等设备的输入,并通知模型和视图做出相应的改变。在GUI应用程序中,直白的说,其实就是控件的事件处理函数,它与界面相关和模型都相关,它从界面获取数据,然后调用模型的函数,有时还会直接更新用户界面。

控制器(Controller)不是业务逻辑,理论上只是很薄的一个胶合层,但是很多新手把业务逻辑写在控制器里,导致模型只剩下数据了,让人产生控制器就是业务逻辑,模型就是数据的错觉。

1.2.2 MVP模式

MVC模式解决分离用户界面和业务逻辑的问题,但是还有一个重要的问题没有解决: 控制器是界面相关的,没有办法为控制器编写单元测试程序。为了解决上面的问题,MVP模式应运而生。MVP是Model-View-Presenter简称。

MVVM模式在嵌入式GUI AWTK 中的实现_第2张图片

  • 模型(Model)。模型还是MVC中的模型,这里不再赘述。

  • 视图(View)。视图还是MVC中的视图,但它不需要向模型注册改变的事件通知了,这个由呈现逻辑去做了。

  • 呈现逻辑(Presenter)。Controller变成了Presenter只是表面现象,最重要的是MVP对视图进行了抽象,呈现逻辑不再向控制器那样直接访问具体的视图了,而是通过视图的接口去访问视图,视图的接口是抽象的,可以有不同的实现,所以可以方便的Mock出一个视图,让编写呈现逻辑的单元测试程序成为可能。注意,这里视图的接口并不是通用的,每个视图都有一个独立的接口,有一个真正的实现和一个用于测试Mock的实现。

从理论上讲,MVP模式已经很完备了,它很好的分离的界面和实现,也可以为呈现逻辑编写单元测试程序了。但是从工程角度来看,MVP却有一个非常致命的缺陷:要编写大量无聊的代码!

为了方便说明,我们以一个编辑图书信息例子,看看要写哪些无聊的代码。这个例子非常简单,却要写不少无聊的代码:

  • 1.初始化的时候,要为控件注册事件处理函数,比如为『保存』按钮注册事件处理函数。

  • 2.初始化的时候,要把图书信息,如书名、作者和出版社等信息从模型中取出来,一个一个的设置到视图的控件中去,在这个过程中,可能需要对数据格式进行转换,比如出版日期,在模型中是一个整数,在视图上表现为一个字符串,这就需要转换。

  • 3.在编辑结束时,要从视图中把图书信息,如书名、作者和出版社等信息一个一个的取出来,再保存到模型中去。在这个过程中,可能需要对数据格式进行转换,比如前面的出版日期,要把视图中的字符串转换回模型中的整数。

  • 4.View都有一个接口定义,有一个真正的实现和一个Mock的实现。

这些代码很简单却很无聊,在每个有界面的模块中,都遵循同样的规律,却又完全不同,不得不重新编写。

1.2.3.MVVM模式

把MVP模式这些规律找出来进行抽象,通过一些规则在视图和模型建立联系,也就是数据绑定和命令绑定,就形成了MVVM模式。MVVM是Model-View-ViewModel简称。在MVVM中:

  • 模型(Model)。模型还是MVC中的模型,这里不再赘述。

  • 视图(View)。视图还是MVC中的视图,但它不需要向模型注册改变的事件通知了,这个由数据绑定去做了。

  • 视图模型(ViewModel)。 ViewModel不是Controller也不是Presenter,视图模型是视图还是模型?按MVVM的发明者John Gossman的话说,视图模型是视图眼中的模型。放大镜下的虫子还是虫子,所以视图眼中的模型还是模型。视图模型与视图没有直接关系,是可以为之编写单元测试的。

呈现逻辑Presenter去哪里了?呈现逻辑从一行行代码变成了一条条数据绑定和命令绑定的规则,对规则的处理和解释成了MVVM框架或公用库,可以在多个项目中共享。

MVVM模式在嵌入式GUI AWTK 中的实现_第3张图片

MVVM模式有下列好处:

  • 强制分离用户界面和业务逻辑。在MVC和MVP中,不能强制分离用户界面和业务逻辑,程序员的一念之间,就导致用户界面和业务逻辑混在一起。MVVM中不需要编写界面相关的代码,自然没有办法让用户界面和业务逻辑耦合到一起。

  • 界面描述文件和程序代码之间具有更松的耦合。通常用XML或RC文件来描述界面,在MVC和MVP中,在界面上增加一个控件或删除一个控件,都会导致相应的代码需要修改。而在MVVM中,采用了面向意图的编程,界面上表现的只是一种意图,至于在程序中,谁去实现,怎么实现,甚至有没有实现,界面都是不关心的,所以界面和代码之间值的耦合是很松的。

  • 不需要学习GUI的API。通过数据绑定和命令绑定建立视图和模型之间的联系。用声明式的规则取代命令式的代码,不需要写界面相关的代码,所以不需要学习GUI的API,无论是采用Qt还是AWTK,都用同样的方式开发。

视图模型和模型并不相同,之所以要引入视图模型,主要原因有:

  • 模型中的数据有时并不适合直接显示在视图上。比如出版日期,在模型中是整数,直接显示出来,用户就看不懂,需要转换成人类可以理解的字符串。

  • 模型中的一个数据项可能以多种形式呈现在视图上。比如出版日期,除了显示出版日期外,也可能把最近出版的书,显示一个新书标志。

  • 视图中的输入数据和模型中的存储数据,它们的格式有时可能不同。比如出版日期,视图上输入的格式和模型里存储的格式就不一样。

  • 视图需要视图模型提供数据校验规则来判断视图上的输入是否合法。

  • 有些数据是有依赖关系的。比如在输入收货地址时,选择省份时,城市列表跟着变化。

  • 有些状态不属于业务逻辑,但是需要保存下来。如为了支持撤销操作,需要保存命令历史记录。

  • 在C/C++等静态语言中,没有办法通过函数的名称去调用对象的成员函数,也没有办法通过属性的名称去访问对象的成员变量。视图模型需要提供一种机制来实现这些功能,否则绑定规则就没法实现。

MVVM 的缺点。

  • 内存问题。据说WPF内存开销很大,即使在PC上也大得让人无法忍受(常有人借此来反对MVVM)。WEB前端流行的MVVM框架,像React和Vue.js等,采用虚拟DOM的方式,内存需求可能有大幅度增加。

  • 性能问题。MVVM通常的做法是,模型有变化时会刷新整个界面。如果采用虚拟DOM的方式,还需要重新构建一个虚拟DOM,与原来的虚拟DOM比较,性能开销就更大了。

  • 调试问题。如果没有工具的协助,数据绑定会让调试变得困难。

以上这些问题在手机和PC上,已经不是什么大问题了,但对于嵌入式系统来说,仍然是难以跨越的障碍,所以目前几乎没有针对嵌入式平台开发的MVVM框架。

1.3 AWTK-MVVM

AWTK-MVVM是一套用C语言开发的,专门为嵌入式平台优化的MVVM框架。它实现了数据绑定、命令绑定和窗口导航等基本功能,使用AWTK-MVVM开发应用程序,无需学习AWTK本身的API,只需学习绑定规则和模型的实现方式即可。

与其它MVVM框架相比,AWTK-MVVM特点有:

  • 代码小。

    • 核心代码:约3000行。
    • AWTK相关代码:约700行。
    • jerryscript相关代码(可选):约1700行。
  • 性能高。核心代码用C语言开发,其性能与直接使用AWTK差别不大。

  • 内存开销小。

    • 一条绑定规则大概需要150字节。一个窗口上若有10条绑定规则,内存占用了也就1.5K。
    • 列表中的绑定规则可以共享,额外增加的内存开销,比例也是很小的。
  • 隔离更彻底。在AWTK-MVVM中,界面和绑定规则在XML中描述,开发应用程序时只需要开发模型(也就是业务逻辑)即可。除非通过特殊手段,开发者没有机会直接去访问视图。

  • 易调试。

    • 提供视图模型的框架生成工具,避免手写代码造成的错误。
    • 增加了各种异常处理的LOG信息。
    • 提供大量的demo以供参考。
    • 开放源码,调试方便。
  • 支持多语言开发。

    • 目前支持C语言和JS。
    • 以后会根据需要支持新的编程语言。

这里支持的多种编程语言与AWTK的脚本绑定是完全不相关的概念:这里是让应用程序的业务逻辑可以用不同的语言来开发,而AWTK的脚本绑定是让应用程序可以使用不同的脚本语言来调用AWTK的API。

  • 可移植到其它GUI。AWTK-MVVM是为AWTK设计的,但是我们隔离了与AWTK相关的代码,让它可以移植到其它GUI。AWTK相关的代码仅仅700来行,可见移植到新的GUI是非常容易的事情。当然,AWTK可以满足常见的需要,这样做只是给开发者提供更多选择。

AWTK-MVVM也有些限制,目前不支持界面元素动态生成,这时可以结合传统的方法开发。以后AWTK会支持WEB前端流行的框架如Reactjs和Vuejs,在高端平台(如手机、小程序和桌面程序)中应用。

在后面的章节中,我们将详细介绍AWTK-MVVM的具体用法。

你可能感兴趣的:(ZLG开源GUI,AWTK)