这个东西是硬伤，框架？自带的mvc？ 自带的UIViewController UIView UINavigationController 这些算不算？当然算的，cocoa框架嘛，大家都知道。
其实，我想分享的是：整个软件设计的代码结构管理。在阅读了不少源码后，总结出来的好的设计代码结构分布逻辑。
一开始，我们学会了简单的使用UIButton，UIImage等这些常用的视图类的时候，我们其实已经能够写出来一般的软件了。常见的功能，这里添加一点，那里添加一点，这里一个网络请求，这里一个bool类型判断，例如常见的：isDownding? reLoading?
这些，我们经常在ViewController中就直接写了，于是，飞快的打出来：@property(nonatomic, assign)BOOL reLoading; 然后代码中，多处引用的地方进行处理。
而如果加上一个网络请求，数据柔和，加上几个成员变量，NSArray， NSDictionary, 什么的，再接着，多上几个又臭又长的正则匹配什么的。可以想象，这个ViewController已经非常长了。上图演示：
好了，我们开始来改进代码了，第一步，把基本的view独立出来一个view文件的存放，分离出来。这样子至少省了3分之一的代码，再viewController中，而且极大的提高了代码阅读效率。直接看viewController就能看完整体逻辑。而可以先不管具体实现。
然后接着，我们又觉得还是不够，不够精简。对。于是，我们把数据独立出来。对抽象独立出来。建立专门的对象存储数据对象。可以发现，无一例外的，所有的大型软件都会这么做。也可以省了好多代码，提高阅读代码体验，极大的解耦了代码。这两种方法相当的基础，基本上做完了。至少代码可阅读了。入门了。现在的文件结构是这样的：
好看了好多。
好了，我们已经基本排版好了文件结构以及基本的代码分布问题。但是，这只是入门了而已。
下面的就是基于软件的复杂度需求进行变更的：
1.抽离出来网络请求的部分：
原因如下：a.网络请求，总会有错误返回码，能方便的增删查减，代码更容易找。
b.网络请求，虽然自带的网络请求也是可以一句话，BLock返回处理结果，但是，要基于自己的业务逻辑进行封装，一定程度上减少藕合度，提高复用性。
c.对于特俗的网络请求，例如http的post请求，就需要自己独立进行封装数据格式了。
2.基于数据的复杂度，进行相应处理，可以添加自己的业务逻辑的数据库处理操作。可以添加各种自定义类型的数据类。这样做的好处，也是抽离代码，减少耦合。
最后上传一张前人总结的，仅供参考的图片：
这里的分类方式真的只能仅供参考，具体情况还要基于实际项目的分析，不能一概而论的。
That‘s all。