MVVM 面向接口型框架封装和单元测试

大家好,今天给大家带来一个我自己开发改造的 MVVM 封装框架。代码不难,但我更想说一些我在开发这样一个架构过程中的想法和思路,我们不仅要善于作一个搬运工,更要自己多多造轮子,我们程序员就是会折腾嘛。

先送上源码地址:https://github.com/G-Joker/WeaponApp

多提一句,这个 App 是我和朋友最近正在努力开发的一款 app,涵盖绝大多数使用场景和技术 ( RxJava + Retrofit + MVVM + 插件化 + 组件化 + 全平台分享+ 服务端 ) 。尽量使用最优雅和最高级的方式来开发业务代码。使用这套框架可以快速构建 app,并能够进行高效的维护。

希望大家可以 star 一下,提一些建议,帮助我们更好地完善它!

在讲具体的实现和思路之前,我们需要多说一些东西,可以说是封装的动机吧,或者可以解释为什么要用面向接口的思想来封装。

去年的时候,MVP 在移动端比较火热,一直持续到现在,MVVM 作为更为高雅和清晰的开发架构,使用的人不是很多。不像MVP,我在研究的时候,想搜索一些封装的资料,发现多数只能找到 dataBinding 的资料,但很少有教你怎么封装的。 「Google」爸爸的 databinding 为我们提供好了轮子,我们实际上按照官方的使用方式来使用 MVVM 已经是比较简单了,只需要在 View 里构建 VM ,在 VM 里维持一个`Model`引用,进行相关数据的绑定即可。可以说是非常好用了。

那么,为什么要特别地再封装一下呢?

这就和我们设计架构的目的和思路有关了。当然了,还有作为程序员,肯定还是希望能写出最优雅、最简洁、最高级的代码,我们都是偏执狂

设计思路:测试驱动、面向接口、隐蔽实现

首先,我们要明确一点,不论是 MVP 还是 MVVM ,它们都不一定会让你用更少的代码来实现一个页面,代码量可能会更多。它们能做到的就是做到数据、逻辑、视图关系的解耦,提升代码的可维护性、可读性、设计性和可测性。

MVVM 中,ViewModel 层是 View 和 Model 的中转层,View 专门用来处理 UI 的操作,Model 是一些数据实体,ViewModel 操作一些和数据处理相关的绑定操作,因为 databinding 的`双向绑定`特性,最好的封装应该是让 View 层只有绑定 ViewModel 和一些必要的 UI 操作,整体的逻辑和思路干净整齐,ViewModel 是一个个功能单一方法的集合。

「单一原则」是我们写代码的时候一定要养成的好习惯,它不仅能帮助我们写出更优雅的代码,也是代码具有可测性、逻辑性和可维护性的要求。

MVVM 单元测试很方便,因为有了双向绑定。只需要测一下 ViewModel 的方法,方法通过了即可验证数据和 UI 逻辑。我们写代码的时候,就应该保持好设计性,尽量做到让代码的可测性很强,保持单一原则,隔离好 View 和 Model 的逻辑,让代码通过验证方法而不需要真正构造 Activity 实例就能有足够的可测性。为了让代码保持可测行,要求我们代码需要具有设计性,而代码的设计性和单一原则又是单元测试的一个本身要求,两者相互影响,相互驱动。

这就是测试驱动开发。

好了,现在我们代码写的也设计性了,方法也够单一了,但单元测试的时候,ViewModel 作为 View 和 Model 的桥梁,它实际上应该持有 View 和 Model 的引用的,可是单元测试构造 Activity 对象不方便,我们既然是要使用单元测试,就应该尽量避免需要打开页面这样的操作,虽然我们有一些非常强大的第三方单元测试框架能够构造 Activity 和 Fragment 甚至可以验证一些 UI 的操作,但总而言之还是一个比较麻烦而妥协的做法,所以我根据 AndroidFire 这个项目上的 MVP 封装思路,进行了 MVVM 的改造,实现了编译期的多态,通过反射构造类型参数的具体对象,在 Contact 中定义各个层级的接口,ViewModel 进行跨层调用的时候,只关注具体接口的形式,而不关心接口的具体实现和到底是哪个实例实现了他。

这就是面向接口了。

同时,我们隐藏了 databinding 的绑定操作,集成了一些 ListView,RecyclerView,ViewPager 的 databinding 第三方使用库,再通过自定义一些 @BindAdapter 帮助更好的进行 MVVM 开发。即使开发者之前不了解 databinding,按照我们封装的操作流程,开发界面就像堆砖块一样简单高效。

面向接口的框架在作单元测试的时候,我们只需要自己构建出一个空实现的接口实例,即可跳过一些 View 层的 UI 操作或者 Model 层的请求操作,做到真正意义上的单元测试。

说的很抽象,下一节我们来看一下具体代码。

MVVM 封装核心实现

我们先来看下封装的一些基类设计思路。因为「WeaponApp」的页面全是用 Fragment 进行开发的,只需要一个占坑 Activity 作为容器来展示 Fragment,所以我们只针对 Fragment 进行了基类封装:

emm...这是什么。。看着这么多泛型叠加,是不是有点头晕,别急,我们从后往前慢慢看。

BaseView 是一个接口,里面定义了一些必须要实现的方法,比如 databinding 需要的 BR 文件,init 初始化方法等,最重要的是定义了一个基类类型,表示项目中所有的 Fragment 都是这个接口类型,辅助编译期检查。

M extends BaseModel:定义具体的 Model 类型。

VM extends BaseViewModel<? extends BaseViewModel<? extends BaseView,? extends BaseModel>> : VM 的泛型是比较复杂的,Android 中的列表控件都是需要一个 Adapter ,为了管理这些列表 item 的 VM,并且做到统一处理,所以 BaseViewModel 中的两个泛型类型都是没有 extends 来限制范围的,那么为了区分是页面 VM 还是 item 的 VM。在 BaseFragment 中,通过通配符来限定范围,在编译期提醒开发者。

因为使用了 binding-collection-adapter ,所以在使用像 ListView,RecyclerView 和 ViewPager 这类控件的时候,是不需要通过 adapter 来进行管理的,全部都是通过 item 的 VM,通过 MVVM 的形式来配置。

好了,看好了类的定义代码,我们来下最关键的 onCreateView() 方法:

继续跟进 initFragment 方法:

这里有一些 databinding 的绑定操作,就不多细说了,我们来看下中间的部分。

这里的 mViewModel 的类型实际上是 VM,TUtil.getT(this,0)方法的第二个参数传入的是类上定义的泛型位置,比如 VM 在 BaseFragment 中的位置是第一个,那么就传入 0,M 是第二个,那么就传入 1 。该方法将返回具体泛型参数类型的实例。这样做的好处就是我们不需要手动操作构建对象并将引用保存到成员变量上了,只需要定义好具体类型参数的泛型类型,即可通过getViewModel 获取 ViewModel 的具体实例。

继续看代码。model.attachViewModel 将 ViewModel 绑定到 Model,ViewModel 和 View 的绑定以及将 Model 绑定到 ViewModel 是中间一段代码做到的:

通配符实际上是一种具体但未知类型的类型。ViewModel 的 attachView 和 setModel 方法的参数都是泛型参数,所以这里必须通过反射来获取具体的方法实例,再通过`invoke`进行调用方法。

举个栗子

OK,那么我们来看看到底怎么就「傻瓜式」开发了,怎么就单元测试很好使了。比如现在项目中的我的界面,用这个封装框架来写界面的时候,先写一个接口定义类 Contact :

这里定义了 MVVM 三层的类型和接口。当你需要添加接口的时候,只需要在这里添加即可。下面是 MineFragment 、MineViewModel、MineModel 的类定义:

我们可以看到我们写具体类中,所有类的集成格式是一样的,并且我们内部可以通过我们刚刚在 Contact 中定义的接口进行各个层级之间的通信,在编译期,我们并不用关心各个接口具体的实现是什么,具体的实现将被移步到运行期中,这极大的方便了我们的单元测试,这也是多态和里式替换原则的应用。同时我们发现 MVVM 的很多操作在 ViewModel 层都被隐藏了,如果你想使用 BR 文件,就自己定义相对应的 get 方法,并不需要具体的保存一个 model 的成员变量了。下面我们来看看具体的单元测试该怎么写:

比如我们现在要测试 VM 中的 init 方法,其中的 View 接口 testType() 是一个吐司显示,为了通过这个方法,我们如果构建一个 MineFragment 实例,无疑非常麻烦,但在我们这套封装中,我们只需要这样写即可:

我们成功的在单元测试中调用了 VM 的 init 方法,也没有构造真正的 MineFragment,只是自己定义了一个和 MineFragment 同类型的接口,因为面向接口的原因,VM 仍然能对其进行调用操作,我们依然不需要关心 testType() 方法内部到底是不是和 MineFragment 定义的 testType() 方法是不是一样的,因为这里都是 UI 操作,我们不需要在 MVVM 的单元测试中测试它。

MVVM 的强大当然不止于此,还需要读者自己多多发掘。当然,在学习别人的轮子的时候,一定要多多思考,举一反三,不能一味的搬运。

原文发布于微信公众号 - WeaponZhi(WeaponZhi)

原文发表时间:2017-10-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏熊二哥

快速入门系列--MVC--06视图

到了View的呈现板块,感觉ASP.NET MVC的学习也进入了尾声,还是比较开心的,毕竟也有了不小收获。这部分内容相对比较简单,因为之前还专门学习过如何结合...

18110
来自专栏大内老A

如果你想深刻理解ASP.NET Core请求处理管道,可以试着写一个自定义的Server

我们在上面对ASP.NET Core默认提供的具有跨平台能力的KestrelServer进行了详细介绍(《聊聊ASP.NET Core默认提供的这个跨平台的服务...

2128
来自专栏葡萄城控件技术团队

七天学会ASP.NET MVC (六)——线程问题、异常处理、自定义URL

? 本节又带了一些常用的,却很难理解的问题,本节从文件上传功能的实现引出了线程使用,介绍了线程饥饿的解决方法,异常处理方法,了解RouteTable自定义路...

22910
来自专栏大内老A

ASP.NET Core管道深度剖析(4):管道是如何建立起来的?

在《管道是如何处理HTTP请求的?》中,我们对ASP.NET Core的请求处理管道的构成以及它对请求的处理流程进行了详细介绍,接下来我们需要了解的是这样一个管...

1696
来自专栏大内老A

ASP.NET MVC以ValueProvider为核心的值提供系统: ValueProviderFactory

在ASP.NET Model绑定系统中,用于提供数据值的ValueProvider对象通过ValueProviderFactory来创建。在ASP.NET MV...

1918
来自专栏圣杰的专栏

ABP入门系列(7)——分页实现

完成了任务清单的增删改查,咱们来讲一讲必不可少的的分页功能。 首先很庆幸ABP已经帮我们封装了分页实现,实在是贴心啊。 来来来,这一节咱们就来捋一捋如何使用...

2245
来自专栏林德熙的博客

dotnet Framework 源代码 类库的意思

System 命名空间包含基本类和基类,这些类定义常用的值和引用数据类型、事件和事件处理程序、接口、属性和异常处理。

622
来自专栏互联网杂技

node中Express的use深入理解

Express的API 现在学node,不来点Express,都不好意思给人打招呼。但是,我刚接触的时候,觉得好多API,感觉乱糟糟的,没办法,大脑容量不够。不...

2834
来自专栏张善友的专栏

ASP.NET 路由

ASP.NET 路由使您可以使用不必映射到网站中特定文件的 URL。由于 URL 不必映射到文件,所以可以在 Web 应用程序中使用 URL,这些 URL 是描...

1857
来自专栏前端侠2.0

asp。net5的依赖注入 原

昨天读asp.net5的doc,看到了configure的配置时,提到在controller中访问配置就是通过依赖注入的。asp.net5的很多功能都通过依赖注...

541

扫码关注云+社区