框架对整个应用程序的作用非常重要，记得有个朋友说过：用什么框架啊，好好封装一下不就行了吗？但我的理解是，好的封装绝对可以事半功倍，但是如果不按照一定的规则进行封装就会让人有些难以理解了，维护代码的人要疯掉了，我认为架构就是规定怎么去封装的。
在拜读的大神们对框架的构思之后，我决定在我们的项目中进行实践一下。刚到了一家新公司，公司的代码极烂，没有什么设计思想，最终导致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的方法进行更新呢，你也可以这么做，由于我对框架的理解不够深刻，所以只能这么回答。
如果闲tableView碍事就可以这么处理：
- 将 UITableView 的 Data Source 分离到另外一个类中。
别人总结的方法，还没进行实践，只是感觉这么分下去有点更乱了。等有时间实践下。
我们的项目中有个viewcontroller是从1500行减少到800行，虽然较少的不是太多，但是感觉逻辑更清晰了，新增的东西会有一个明确的地方处理，感觉更规范了。
最后感觉架构的使用还是分项目和分页面的，比较简单的界面不用什么架构，复杂的可以尝试划分。对框架的理解比较肤浅，可能有很多理解不对的地方，以后会改正吧。
参考资料：