每当产品经理不停的修改需求时及产品的功能越来越多时。不得不考虑到产品的框架问题。
从步入开发的第一天起，“高内聚低耦合”这个名词一直缠绕在我们的脑袋中。但是作为新手小咖怎么会理解到这个的重要性呢。所以实践出真理。好了，废话不多说马上进入我们的主题。
首先我们先讲讲前几年主推的MVC，在斯坦福大学的公开课上已经很明确的交代了逻辑图。
斯坦福大学MVC模式
Controller : 为Model 及 View 的管理平台
Model ：存放着模型数据
view ：自定义view
1.view 发生触发事件时告诉Controller
2.Controller接收后去处理传给Model去处理
3.Model处理成功后通知Controller ，Controller去更新view
这样的逻辑很清楚也很清晰。但是功能越来越多的情况下。很多处理逻辑到交给了Controller，(如UITableViewDataSoure,UITableViewDelegate....... )就在Controller中实现。时间久了。Controller就变得无比的臃肿。已经违背了“高内聚低耦合”这个名词。
我们应该把 “高内聚低耦合”这个名词改为动词。
这个时候就多出了一个MVVM.
MVVM模式
可以不难看出，其实在MVC中分离多一个viewModel。viewModel主要的工作把Controller的一些工作交给viewModel去处理。ViewController只是管理器，不应该把大部分逻辑放入ViewController去处理，viewModel的加入大大提高了可读性及逻辑性。
viewModel做的事情无非分为 ：
1.获取网络请求
2.处理view的交互逻辑（如UITableViewDataSoure,UITableViewDelegate.......）
现实总是那么残酷。
MVVM解决的方式就是把 处理view的交互逻辑 从Controller放入viewModel 其实说到底就是换汤不换药。所以我针对MVVM模式，做了一个优化
优化后的MVVM
在一个控制器里有很多自定义view，他们的逻辑又是独立的。只是通过交互方式来改变彼此的显示方式及状态。所有逻辑都放入各自的viewModel去处理。当需要去修改其他view的时候则可以通过回调（block,protocol）的方式去修改。这时候就需要在Controller中去处理。
很多技术文 中都把 Controller 当成view 。其实那不是事实上的MVVM，那是MCVM (model, Controller , viewModel).
哈哈，这都是本人的理解，如果本文中有什么错误的地方希望大家反馈。
本文禁止转载
来自 处在水深火热的iOS_林龙
网友评论