原文链接:https://medium.com/ios-os-x-development/ios-architecture-patterns-ecba4c38de52
一.前言
之前一直只是知道MVC/MVP/MVVM/VIPER这几个架构设计.
而且在实际工作中也都是跟着工程已有的代码结构去写.
虽然看着公司的工程是MVVM的架构设计.
但是其实还是传统的MVC架构.
连Apple’s MVC架构都算不上.
最简单的一点我们还是直接把model传给view.
就是说view和model还是强耦合的.他们是互相知道的.
这样就导致你想复用这个view.就必须连这个model一起复用.
这就有点拔起萝卜带着泥的感觉.
在看了这篇文章后纠正了一些概念.
下面是我看了这篇文章后的一些感想.
只是一些基于我已有的理解上的勘误.
就是个小笔记.想深入了解的可以去看原文.
肯定会有很大的收获.
二.Traditional MVC
传统MVC.是把view当成一个整体.
VC把model直接传给view.
然后view在内部根据model的每个属性去更新自己内部的子view
三.Apple’s MVC
而Apple’s MVC不是把view看做一个整体.
而是把view看成一个个基础组件的集合.他是一个集合.
比如view里有titileLabel.imageView.
那么这些子控件都是暴露在view的.h里.
当VC收到model的更新时.
就取model里的各个属性去更新view的titlelabel.imageview等控件.
例子:
如在VC里有个topview.
topview里有个titleLabel
像传统MVC就是把model传给topview.
在topview里取model得titleStr赋值给titleLabel的text
而Apple’s MVC是VC直接取topview得titlelabel.然后把model的titleStr赋给titlelabel的text.
self.topview.titleLabel.text = model.titleStr;
这样VC只给view传递基础类型.所以view不需要知道model
就完全隔离的view和model.他们之间是不可见不互知的.
其他位置想用这个view就可以直接拿去用了.你再拿着个view跟任何model绑定都可以.
四.Reality Apple’s MVC
设想永远是美丽.然后现实总是残酷的.
随着业务逻辑的上涨.
VC里会处理越来越多的逻辑操作.
比如数据的转换(转成view可以直接使用的数据) ——>>> 痛点1
比如处理用户的逻辑代码. ———>>> 痛点2
Apple’s MVC最后在我们手里其实变成了如上图这种情况.
最后就变成了Massive VC
五.MVP
MVP就将Apple’s MVC的两个痛点转移到了Presenter层.
Presenter专职处理数据转换和用户的响应事件.
解决痛点一
如Presenter在内部将model的属性转成view可以直接使用的基础类型(如string.int….)
VC拿着Presenter转化后的基础类型数据传给view并更新view
解决痛点二
view的响应事件直接抛给Presenter.Presenter去更新model数据.
然后通知view去更新
六.MVVM
感觉MVVM好像跟MVP一样的.这里的VM好像就是MVP里的Presenter
感觉他们的区别就是MVVM引入了Binding理念.
通过KVO或者Notification.(更好的解决方案是引入RAC或者Rxswift)
在VM里把View和model做了一个双向绑定.
既当model更改的时候.VM让View做出相应的更新
当用户操作了view后.VM让model做出相应的更新.
View和model依然相互不知道彼此.
但是这样下来每个模块的职责就变得非常清晰.
VC: 1.管理view的声明周期.2.初始化vm和view的双向绑定
View: 仅布局子view
VM: 绑定view和model.处理各种业务逻辑后通知view和model各自更新
Model: 存储数据
七.VIPER
MVVM把各个模块的职责都划分的很清楚.
但最后当这个功能模块庞大的一定程度的时候.
VM也将变得非常非常臃肿.因为他做了太多的View和model的绑定逻辑.
VIPER就在MVMM的基础上解决了这个问题.
VIPER将VM又拆除了一个Interactor.
这个Interactor专职负责VM和View双向绑定的逻辑处理.
对于VIPER我也不是很理解.
只是简单的知道.所以就不多说了.
想了解的还是看原文把.
八.My Conclusion
其实不管什么架构其实都是在拆越来越臃肿的那个模块.
比如MVP/mvvm都是拆分vc
而VIPER就是拆MVVM / MVP里的VM/Presenter
哪个肿了就拆哪个.
最后引用原文的结论作为总结.
九.Conclusion
We went though several architectural patterns, and I hope you have found some answers to what bothered you, but I have no doubt that you realised that there is no silver bullet so choosing architecture pattern is a matter of weighting tradeoffs in your particular situation.
Therefore, it is natural to have a mix of architectures in same app. For example: you’ve started with MVC, then you realised that one particular screen became too hard to maintain efficiently with the MVC and switched to the MVVM, but only for this particular screen. There is no need to refactor other screens for which the MVC actually does work fine, because both of architectures are easily compatible.
