目录
概述
傻瓜图解
MVC
一个正统的MVC、三者的任务是什么?
关于View到底该不该写一些业务代码
胖Model与瘦Model
强业务、弱业务
胖Model
瘦Model
该用哪个？
MVVM
Model
View
ViewModel
Controller
ReactiveCocoa对于MVVM的意义是什么？
MVCS
MVP
VIPER
关于架构设计、一些观点
控制好Controller的代码量
对于MVX如何选择
无论用哪种模式、都要深刻的理解每个模块不同的职责
概述
其实只要是架构上的设计、本质上都是三个角色：数据管理者、数据加工者、数据展示者。
不管是MVC、MVVM、MVP、VIPER或者任何新的设计模式、都跳不出这三个角色。无非是把数据管理者的工作进行拆分、唯一的界定标准就是把工作拆分的粒度大小。
而无论哪种思想、最终都逃不开三个问题的取舍。代码量、通用性、可读性。
这里我主要写的是MVC和MVVM、对于其他的架构只是略微提及。
傻瓜图解
这两天总有人跟我说我想看Demo...我想了想觉得Demo其实也不太直观、干脆画几个图好了。
主要是想表达每个模块里应该放什么类型的东西、线可能有连得不对的地儿。亲们尽量意会吧。
MVC
MVC--胖Model
MVC--瘦Model
MVC--胖瘦结合
MVVM
MVP
VIPER
试了试...感觉画着费劲。能理解了前面几个的话、看文字应该也能理解VIPER吧。
MVC
MVC就是典型的着重通用型与可读性、这正是一个作为万物之初的架构所需要保证的事。简单、易学。
Model进行数据管理
View进行数据展示
Controller负责根据需求对Model以及View进行调配。
不过和广义的MVC不同、客户端(别的我不知道啊、起码iOS)由于UIViewController自带一个容器View、所以除了上述的正统任务之外、Controller还需要承担View的生成、布局等的任务。
一个正统的MVC、三者的任务是什么?
所以、我们可以将MVC三者的任务再进一步细化一下
Model:
为Controller的读取提供数据
为Controller的写入提供接口
为Controller提供基本的业务组件
最常用的就是网络请求之后Json转Model、写入数据库之前Model转Json。
View:
界面的展示
响应与业务无关的事件(动画效果、点击反馈、点击事件的开关保护等等)
何为业务事件：Model数据的改变、网络请求的发送、页面的跳转、页面的刷新等等。
Controller
管理self.view的生命周期
负责生成所有的View实例、以及布局。
将恰当的Model交付给View展示。
监听来自View与业务有关的事件、通过与Model的合作、来完成对应事件的业务。
关于View到底该不该写一些业务代码
其实自己以前。也会图方便、把一些自认为的弱业务写在View里。
举个例子：
一个Cell、有用户Nickname、还有一个用户头像的Button。
点击事件肯定由Cell捕获。这个时候跳转用户主页的动作、该由View完成、还是传递给Controller？
假设我们交由View、也就是当前的Cell跳转了。很方便、省去了写代理的小十行代码。
并且这个Cell也可以挪到其他页面去使用、一样能跳到用户主页、又省去不少代码。
有一天、产品让你在某个页面点击头像不执行任何动作。
咋办呢？机智如你、给这个Cell添加了一个bool值来控制是否跳转就好了。
又过了几天、产品让你在某个页面把这个头像弄成点击之后弹出举报框。
这怎么搞呢？也不是不行、你又给这个Cell添了一个枚举的type。这简直完美、不同的Type执行不同的事件、你顺便取消了那个bool、把他也写成了一个type。
又过了一阵子、产品又告诉你当满足某些条件的时候、这个头像跳主页。另一些条件的时候、这个头像不能跳。
于是、你终于写了个block或者代理、在点击之后执行一下再看下一步怎么跳转。
此时、回过头来再看你的Cell、已经面目全非了、充斥着各种业务判断。
可能你会说、如果产品真的这么二逼。那我干脆再copy一个Cell就好了啊。
但是别忘了、你当初这么设计这个Cell的时候可是为了节省下页面跳转的小十行代码、而你现在却要为此付出copy一整个Cell的代价。
其实还有一个更重要的问题、就是你这个View的模块复用基本为0
假设你需要另起一个新的工程写一个demo、如果用这个View你首先要解决一大堆跳转代码上Controller 文件的缺失、然后还会发现、原来写的很多逻辑、type在这个demo里毫无用处。挨个删除、梳理逻辑又要耗费很多时间。
而这些将来会发生的问题、如果你最开始不把业务事件代码硬写进View里、一件都不会发生。
胖Model与瘦Model
这里先要引出两个概念。强业务、弱业务。
二者关键的区别是代码变动的频率大小与涉及模块的多少。举两个例子：
1、比如把时间戳转化、小数点的格式化或者修改A属性进行一系列计算并且改变B属性、这种业务就属于弱业务。
2、再比如一个一个订单Model的确认收货、就应该归入没办法归入弱业务、因为涉及网络请求、加密等等多个底层模块。
胖Model
主旨是Controller从Model里拿到的数据、不需要进行更多的判断、处理等操作、就能使用。举个例子:
Raw Data: timestamp:1234567FatModel:@property(nonatomic,assign)CGFloattimestamp; - (NSString*)ymdDateString;// 2015-04-20 15:16- (NSString*)gapString;// 3分钟前、1小时前、一天前、2015-3-13 12:34Controller:self.dateLabel.text = [FatModel ymdDateString];self.gapLabel.text = [FatModel gapString];
这就需要将弱业务、写进Model、很好的满足的复用的需求。
胖Model也是存在问题的、就是移植的困难。毕竟业务再弱、也是代码、当项目成长到一定程度、这个Model也将会变得相当的臃肿。
瘦Model
就是要把MVC的M贯彻倒底、除了业务的表达啥都不管。
但是这样又会导致Controller中的代码变得异常臃肿(废话么、连时间戳转化都要交给Controller不肿才怪)
所以瘦Model要借助一些外来的辅助模块（索性可以叫Helper）来对弱业务做抽象。举个例子:
Raw Data:{"name":"casa","sex":"male",}SlimModel:@property(nonatomic,strong)NSString*name;@property(nonatomic,strong)NSString*sex;Helper:#define Male 1;#define Female 0;+ (BOOL)sexWithString:(NSString*)sex;Controller:if([Helper sexWithString:SlimModel.sex] == Male) { ... }
该用哪个？
我个人用胖Model用的比较多、但是也借助了一些瘦Model的思想。举例来讲：
除了上述很明确的可以放到Model里的弱业务之外、像一个订单中的确认收货、发货、申请退货等等操作、他们既不算特别强的业务、而且还有很高的复用需求(订单列表和订单详情都需要确认收货)。
这种业务有一种特点、就是代码就在哪里。不管你放到哪、都只能挪不能删。但挪到哪、都不完全合适。从定义上来讲十分莫若两可。个人觉得：
这种的业务：能不放在Controller里就不要放
你可以干脆放到胖Model里、毕竟将来拆分一个400行的Model、比拆分一个1400行的Controller容易得多。
你也可以单独新建一个Helper、配合着Model来完成业务。这样想移植页面就单用Model、想带业务移植就带着Helper(其实这个思路已经很接近MVP了、但是还差提点。MVP还需要为View提供数据)。
MVVM
弱弱的一说、我并不推荐iOS中写MVVM(因为入侵性实在太强)、不会教你怎么用RAC怎么写出MVVM、只是想让你理解什么是MVVM
MVVM现在已经是一种非常成熟的思想了。应用也十分普及、例如Vue以及小程序。
MVVM的初衷也是为了Controller减负。
刚才的胖Model只从Controller移植走了一些简单的弱业务。
而ViewModel则干脆把数据的处理全部从Controller移植了出去。
理想上相同的输入(比如网络服务响应)将会导出相同的输出(属性的值)。
简单的说一下M、V、VM的在架构中所扮演的角色。
Model:
和正统MVC中的瘦Model一样、只承载最基本的数据单元。
@interfaceUserListModel:NSObject@property(nonatomic,strong,readonly)NSString*userName;@property(nonatomic,strong,readonly)UIImage*portraitImg;@end
View
其实也和正统的MVC一样、只做展示工作、不承接任何业务逻辑。
但是需要注意的是、有时候也会在View中将ViewModel与View做一些绑定工作(ViewModel本质上也算是Model层、所以View并不适合直接持有ViewModel）。
- (void) awakeFromNib { [superawakeFromNib]; RAC(self. portraitImgView, image) = RACObserve(self, viewModel. portraitImg); RAC(self. userNameLabel, text) = RACObserve(self, viewModel. userName);}
ViewModel
提供了这个页面展示所有需要的数据的一个对象。
举一个简单的例子：
@interfaceUserListViewModel:NSObject@property(nonatomic,assign,readonly)BOOLloading;@property(nonatomic,strong,readonly)NSArray*userList;@property(nonatomic,strong,readwrite)NSString*searchUserName; - (void) searchUser;- (void) deleteUserWithModel:(UserListModel *)model;- (void) loadMoreUser;
这个ViewModel里涵盖了所有页面展示需要的要素。用户列表、搜索名称、是否需要显示网络加载的小菊花。
并且涵盖了对这些数据的所有操作方法。加载更多、搜索、删除。
但是、ViewModel到底也是一个Model层、不应该引入UIKit(View层)。如果删除需要弹窗、那么这个弹窗动作是不应该交给ViewModel来搞的、因为这已经不属于数据处理的范畴了
仔细想想、这个ViewModel其实就是把Controller中与页面相关的数据处理代码挪进来了而已。
如此、我们设置可以脱离View层。拿着这个ViewModel去跑单元测试。简直碉堡。
Controller
虽然MVVM中没有体现出C的字眼、但是实际操作肯定是要遵循着View <-> C <-> ViewModel <-> Model。
起码在iOS中是、这和Vue中简单粗暴的方式不同:
//页面里
{{message}}
{{value}}
//js文件里newVue({//数据data:{ key:'welcome vue', arr:['apple','banana','orange','pear'], json:{a:'apple',b:'banana',c:'orange'} }//方法methods:{ add:function(){//push 添加元素this.arr.push('tomato'); } }})
因为Html中并没有明确的Controller的概念、整个Html文件就是Controller容器。
和iOS的区别很明显：
除去精炼的写法、整个Html文件所关联的js资源都可以无障碍互通、所以View层无时无刻不持有着Model层、在View层直接绑定更方便。
所以iOS中Controller的作用就显而易见了
Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上、Controller知道应当展示哪个View、Controller也知道应当使用哪个ViewModel、然而View和ViewModel它们之间是互相不知道的、所以Controller就负责控制他们的绑定关系。
ReactiveCocoa对于MVVM的意义是什么？
ReactiveCocoa并不是MVVM思想的根本、不用ReactiveCocoa也能MVVM、用ReactiveCocoa能更好地体现MVVM的精髓。
我一直强调MVC中的M与V是应该尽量不要互相持有的。
这个时候如何把原本松散的二者通过C紧密的联系起来、就要进行数据绑定。
而这种数据绑定、iOS本身并没有什么太靠谱的办法（就像刚才前端例子中的
{{message}}
、这种写法）。
虽然KVO、Notification、block、delegate和target-action都可以用来做数据通信进而实现绑定
但都不如ReactiveCocoa来的《《《优雅》》》。
对、这就是我开始说为什么RAC对于MVVM不是必须的。
如果不用ReactiveCocoa、绑定关系可能就做不到那么松散那么好、但并不影响它还是MVVM。
MVCS
将数据持久化的代码移植给了store...
MVP
实际上就是将Controller中关于Model与View的调配处理的代码移植了过来。各部分分工如下：
View
负责界面展示和布局管理、向Presenter暴露视图更新和数据获取的接口
Presenter
负责接收来自View的事件、通过View提供的接口更新视图，并管理Model。
Model
和MVC中的一样，提供数据模型
VIPER
除了View没拆、其它的都拆了....
在MVP的基础上新增了Interactor与Router
View
提供完整的视图。负责视图的组合、布局、更新
向Presenter提供更新视图的接口
将View相关的事件发送给Presenter
Interactor
维护主要的业务逻辑功能，向Presenter提供现有的业务用例
维护、获取、更新Entity
当有业务相关的事件发生时、处理事件、并通知Presenter
Presenter
接收并处理来自View的事件
向Interactor请求调用业务逻辑
向Interactor提供View中的数据
接收并处理来自Interactor的数据回调事件
通知View进行更新操作
通过Router跳转到其他View
Entity
和Model一样的数据模型
Router
提供View之间的跳转功能、减少了模块间的耦合
初始化VIPER的各个模块
VIPER与其他的架构相比最大的优势就是粒度简直细化成了尘埃、极大的提高了可测性。
但问题也相当显著、层级越多、数据传递的工作量(API)就越大。文件越多、新建一个页面的成本也就越高。
关于架构设计、一些观点
除了MVVM、它对iOS的入侵性简直太高、主要取决于团队的决策(比如是不是新项目、Leader是不是想玩玩看)。
控制好Controller的代码量
随着项目的进行、代码量最多只能优化、膨胀不可避免。
而在没办法继续精简的前提下、想控制Controller的代码量。就要在可读性和通用性之间进行取舍。该挪走的时候就挪走吧、毕竟梳理一个单独的模块、比梳理一个几千行的Controller要方便多了。
对于MVX如何选择
其实完全要看业务的性质以及复杂度。
如果你一个页面只有一个UITableView、搞出一些奇淫技巧其实意义 不大、徒增烦恼。踏踏实实用MVC对大家都好。
如果感觉业务里有非常多的View与Model互通、或者需大量复用、可以用MVP。
如果有大量的数据读写、可以用MVCS。
如果业务相当的复杂、耦合让人浑身难受。做好模块化或者干脆VIPER才是出路。
无论用哪种模式、都要深刻的理解每个模块不同的职责
比如MVVM里的VM、既然是Model层、就不要把UIKit放进去。
再比如MVP中的P、既然是为了帮助Controller协调M与V而生、就不要把与二者无关的工作也抢过来干。