iOS框架MVC+MVVM结合的实战

    框架对整个应用程序的作用非常重要,记得有个朋友说过:用什么框架啊,好好封装一下不就行了吗?但我的理解是,好的封装绝对可以事半功倍,但是如果不按照一定的规则进行封装就会让人有些难以理解了,维护代码的人要疯掉了,我认为架构就是规定怎么去封装的。

公司主营业务:做网站、网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传,提高企业的竞争能力。成都创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化,感谢他们对我们的高要求,感谢他们从不同领域给我们带来的挑战,让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。成都创新互联推出扎鲁特旗免费做网站回馈大家。

    

    在拜读的大神们对框架的构思之后,我决定在我们的项目中进行实践一下。刚到了一家新公司,公司的代码极烂,没有什么设计思想,最终导致controller类的代码达到2000行,最多的三千行,非常不利于代码的复用,本来极为类似的界面,继承一下就可以搞定的东西,竟然实现了两次,可以公共使用的东西就更多了,所以激起了我对代码进行优化的想法。

    我们的程序是运行于iPad上的,所以每个viewcontroller的控件和事件比较多,导致的代码集中到了VC上,读过被误解的 MVC 和被神化的 MVVM后,决定使用优化过后的MVC。

    View,就像大神的分析view是一个层,可能有多个类组成,我们的界面以前是storyboard编写的,我不准备用用纯代码实现一遍,于是加了个viewUtil的类,让所有的view上的属性也作为viewutil的属性,这个类我准备用来监听viewModel(借鉴MVVM)的属性,一旦viewModel的属性进行改变,view也要进行改变,view的改变就在viewUtil类中进行实现。这样view这一层(初始化和改变状态)有了处理的地方了。

    ViewModel,借鉴MVVM可以让架构的思路更清晰。我们平时用于数据传输的model用来存放网络上请求过来的数据的,不一定和页面上的元素一一对应。比如页面上有个开关,用于控制某个东西的显示和隐藏的,model里不会存放,这个时候我们在viewModel创建一个bool属性showSth,就是将一个页面所有的可变元素和viewModel的属性一一对应,这样我们在viewcontroller里修改了showSth=YES;由于view监听了viewModel的这个属性,让某个东西显示了。这样逻辑就变的清晰了,界面转化成了具体的属性来操控。

        viewModel也是用来存放数据(例如网络请求的结果数组)和处理逻辑(排个序什么的)的地方,但是不包括网络请求,因为网络请求也放到viewModel里的话,viewModel就会变成第二个viewcontroller,不利于对程序流程的掌控,还有就是大量的代码从viewcontroller转移到了viewModel。

    viewController,viewcontroller还是用来接收所有交互的,只不过做了一个中转作用(至于如何做中转,下面会有介绍),交给其他的类进行处理,这么做可以减少viewcontroller里的代码,又可以把所有的交互处理集中到了一个地方,可以方便调试快速找到问题。

    

    Service,这个类处理网络请求,做成功和失败的判断处理,还可以加工数据把数据加工成viewModel类所需要的类型,比如数组包含相应类型的Model之类的。

    Model,数据存储的类,就是我们平时使用的Model,可以进行数据持久化的处理。

    所以一个完整的交互流程大概是这个样子,例如view接收到了点击某个按钮的事件,view用代理回调给viewcontroller做处理,比如要去请求来数据进行展示,就调用service类进行网络请求,返回结果后又会回到viewcontroller里,然后viewcontroller将数据赋值给viewModel的属性dataSourceArray里面,这个时候由于view监听了dataSourceArray这个属性,view就会直接调用tableView进行刷新。这样就是这个架构的交互流程。

    

    将view和view的刷新放到view层,网络请求进行独立,viewcontroller处理所有的东西,viewModel处理运算逻辑等和对页面的元素进行表示和控制,这是整个架构基本的对类职责进行规定。

    为什么不在请求成功后让viewcontroller直接调用view的方法进行更新呢,你也可以这么做,由于我对框架的理解不够深刻,所以只能这么回答。iOS框架MVC+MVVM结合的实战

    

  如果闲tableView碍事就可以这么处理:

  • 将 UITableView 的 Data Source 分离到另外一个类中。

别人总结的方法,还没进行实践,只是感觉这么分下去有点更乱了。等有时间实践下。

    我们的项目中有个viewcontroller是从1500行减少到800行,虽然较少的不是太多,但是感觉逻辑更清晰了,新增的东西会有一个明确的地方处理,感觉更规范了。

    最后感觉架构的使用还是分项目和分页面的,比较简单的界面不用什么架构,复杂的可以尝试划分。对框架的理解比较肤浅,可能有很多理解不对的地方,以后会改正吧。

参考资料:

被误解的 MVC 和被神化的 MVVM


猿题库 iOS 客户端架构设计

浅谈iOS中MVVM的架构设计与团队协作    


网站名称:iOS框架MVC+MVVM结合的实战
分享地址:http://csdahua.cn/article/gjsjgi.html
扫二维码与项目经理沟通

我们在微信上24小时期待你的声音

解答本文疑问/技术咨询/运营咨询/技术建议/互联网交流