架构之果 —— MVCH模式：
前言：
每次准备写新的项目，特别是需要重构以前经外包人员或者N任开发人员的手写的项目的时候，总会不自觉的看看当年所学习的关于架构方面的知识：每次看感觉都不一样！
文末附自己研究并实践的新的架构模式——MVCH模式：
友情提示：本篇重点旨在供iOS开发者参考使用的，其他程序猿（媛）可跳过！
一.总侃架构：
1.不要用Common 和Core等文件夹：
这个问题，一定要避免，因为可能一不小心，后期就会出现无法维护的灾难！
这个核心处理就在于减小类似Common类内部代码的联系和耦合性，从而其他App想要什么就你可以直接拿什么。
2.尽可能考虑项目的可移植性：
就是类与类之间的关系不要太紧密了，造成紧密的方式主要有以下几种情况：
过多的继承关系；
横向依赖过多；
以及MVC中各模块功能不清不楚等。
3.关于业务逻辑内部分层：
不要一上来就分层，说要用MVC架构或者MVVM架构等，应该对整体框架处理好了之后，发现某一块可能特别大，这个时候再考虑应该分几层，应该用什么架构更合适些！
可能一个项目中每个业务逻辑模块用的架构其实都不一定一样哦，但是大部分业务应该是以MVC架构为主的！
二.View层的组织和调用方案
View层常见的问题如下：
View层的组织和调用方案，更改最频繁；
滥用继承的关系；
横向依赖比较多；
View展示与数据处理未分隔清楚。
解决办法要从以下几个方面处理：
1.View层代码结构方面：
重点强调 Private Method 的方法中要考虑其他地方是不是也要用，如日期换算，图片裁剪等就需要单独再写个分类
记住一个原则，当一段代码需要在2个以上地方cmd +c，cmd +v的时候，就要考虑是否单独分割一个类来处理。
但是View的纯粹界面创建不在这里讨论范围内，因为View的布局或者排版对于产品经理来说是有可能经常变动的，所以就不要那么懒了，该初始化还初始化，该懒加载就加载。
2.View层的布局做法：
View层的布局，代码层面用的Masonry，是否可以考虑用用UIView+LayoutMethods和 UIView+AEBHandyAutoLayout感受下。
3.StoryBoard，Xib，Code孰优孰劣：
Code替代StoryBoard更好些，偶尔用下StoryBoard，比方TabBar下的子控制器分类与跳转，可以让每个主模块的界面与界面之间关系更清晰一些，也未尝不可！
4.继承层级多少，度的把控问题：
项目的速度方向成也继承，败也继承！
我没有作者那么排斥继承，但我的意思是继承关系最多不超过3层，一般为2层。
比方说像我以前的空项目：空项目的准备，统一Nav的定制就是2层关系。
还有比方：有时候的继承是要我们的项目继承某个第三方库的某个类，这个时候如果只继承一次，那么就继承呗；而如果比方说A为某第三方的类，B要继承A进行界面方面（比方环信的聊天界面），而C要继承B的部分真正聊天的功能方面，这个时候我的建议是对B和C分别继承A，然后用一个枚举定义，来分别标识B和C界面。一定要打破B和C的关联性！
因为比方说这个时候有另外一个项目：需要用到C中的界面和数据处理方面，那么我只需要拿走A和C即可，如果滥用继承的话，我要拿走A，B，C，这还不算，如果我要改某些地方，我是该在B中改好呢，还是C中改好呢？
所以说，继承的层数最多3层，超过了后面就是代码维护的灾难！
当然，最重要的是，新来工程师学习的成本也很大！
好了，重点来了，引入我的MVCH模式：
三.从N种架构模式中创造MVCH模式：
常见的架构模式有以下几种
MVC、MVVM、MVCS、VIPER，加一种自己发明的MVCH（MVC +Helper）模式。
为何引入MVCH架构模式目的在于：对于无论以上那种设计模式中，都对于业务逻辑的耦合性降低了不少，但是比方在首页中的一个地图类，只需要显示当前位置，以及定位当前位置，那么在导航模块中需要真正的地图，这种情况下，传统的来说，要么把地图功能处理类直接放到最外层去整体协调我们业务逻辑的代码，但这样好像不是太合适，因为毕竟还是属于我们业务方的代码，为何还要放在外面呢？
怎么办呢？
我的处理办法是，在导航类中加入一个Helper文件夹，里面加入 LoctionManager，然后用不同的比方Bool值，比方枚举等来判断是哪个模块的VC调用了让我的LoctionManager 提供具体位置（经纬度）还是要只提供省市区这种情况！这样就可以发现加深了不同业务逻辑中相同功能的交流（好像有点绕口），减少相同功能写过多重复代码的问题！
以上不管种架构模式，核心基础都是MVC架构，但是在实际开发中，开发中的业务无非就分以下三种情况，由简单到复杂模式：
首先按照业务逻辑来分，先分几个模块：之后每个模块再采用相应的架构模式（不一定全是MVC哦）去设计！
1.最简单的（比方登录注册，我的，设置等模块）：
此类单一模块，基本MVC就可以搞定，一般直接用MVC架构模式去处理，甚至来说，有时候一个C（Controller）文件就可以，比方设置常见的TableView界面；
2.大部分的业务（如首页，发现，朋友圈等模块）：
一般设计的业务逻辑不算复杂，比较常用，功能相对单一，这个时候就还用MVC架构模式,对于对应的功能，需要一个Manager管理类来进行协调，可能也有一些只有当前业务模块使用的工具类等，把这2个放到Helper类中即可！
3.当然还有极个别的模块（如之前比较火的视频直播功能为一个模块）:
这样的业务一般就比较复杂了，传统的MVC或者MVVM等架构，要么还没彻底分开，造成胖Controller，要么分的太多，不好管理，建议尝试使用MVC +Helper模式。其中Helper里面可以包含如：VideoManager（视频播放类），网络请求类（RequestManger），ChatManger（聊天类）等，每个复杂功能拆分后放到Helper中去管理！
如果还是觉得不太合适，无法很好解决这个复杂模块那就继续拆呗，试试VIPER架构模式，这是他的中文链接：使用 VIPER 构建 iOS 应用
拿走不谢！
总之：侃了那么多，引入MVCH架构模式的目的是为让各个不同业务逻辑模块之间（特别是VC）总要有那么一丁点联系，就是Helper了！
好了后面几篇就谈谈关于架构的其他方面：
数据存储，网络链接，乃至最后的组件化方案等,欢迎捧场！
最后附上：
一直在学习架构的参考资料：
当年自己学习架构知识的成果展示：
iOS架构漫谈1---架构入门和Controller的内部布局
有问题：加QQ：1824496534，备注：架构，欢迎指导！
