iOS前端的架构设计，我所理解的意思就是，使用什么样的模式或者结构敲代码就是各个类怎么协同工作的、或者文件存放的结构、各个类到底如何分工的。
国外有好多关于iOS端的架构的文章，无奈实在英语水平有限，只看了几篇被翻译过的文章。MVC、MVVM、VIPER等还有几个记不住名字的，但是无论什么架构感觉理解的都不是很深刻，具体写代码的时候也没有分的太清楚，也是怎么方便怎么来。最后导致了来回几次的重构，但是重构完成后，过一段时间再看代码的时候还是感觉结构不够清晰，各个类之间的关系比较混乱。现在的项目也是各种模式混用，比如简单的页面就是MVC的结构，复杂的一些界面就是MVVM的，今天写这篇文章，不是为了分享框架设计的经验的，而是方便以后看看现在对框架的理解有哪些偏差。
引用了一张大家比较熟悉的关于MVC的图
MVC，M是model只用来存储数据的，但是有些人把跟model相关的算法，放在了model里，最后model除了几个属性以外，还有几个相关的方法。V就是view，苹果官方对MVC的要求最谨慎的一条就是view不能持有任何数据，这个也是有道理的，解耦合用的。C是controller，负责业务逻辑用的，包括数据请求、界面逻辑等。这样的分层会导致一个比较常见的结果，就是C中的代码量过大，导致整个类不易懂，不方便以后的维护，单个人感觉，这个并不是MVC的错，而是我们经常误解了MVC的设计初衷，苹果以为我们能做好，但是...，最近看了一篇文章觉得很有道理，是给MVC平反的：被误解的MVC和被神化的MVVM（貌似是大神唐巧写的）。
个人感觉大部分框架都倾向于一个原则，就是单一功能原则，一个类负责一种功能，但是分的越详细的框架，就会导致项目太过冗余。但是某些简单的分工还是有必要的，就像我们平时做的一样，每个网络请求都要单独拿出来，封装成一个直接回调结果的类，就像AFNetWorking一样；数据缓存之类的单独列出；tableView的dataSource单独列出。这写基本工作做完了，感觉使用什么架构都无所谓了，看过的框架意思都是相近的，都是给每个模块分配相应的功能，以上的工作除了一些关于数据和页面逻辑之外，基本上没有太多的东西要处理。这样分层完成以后，controller要处理的就是关于数据和页面的逻辑，和一些事件的监听，唐巧大神的建议就是数据和页面建立单独的类处理，最后导致controller只需要负责分配不同的监听事件就可以了，其实MVC没有太大问题。
再借用一张MVVM的图片
MVVM，没有理解太透彻，感兴趣的可以看一下：猿题库 iOS 客户端架构设计（这篇文章出自猿题库是赞成MVVM的，但是唐巧也是猿题库的，唐巧赞成的是MVC，不知道他们两个会不会打起来），我的感觉就是：M，model，V，view（包括UIView，UIViewController，），VM，viewModel（存储数据、处理页面数据逻辑和事件监听的类），除了我刚才说的基本工作以外，关键的一步就是viewModel和view的绑定，剩下的就是把controller的事全做了，如果不简化似乎也会造成代码太过复杂的问题。我的理解中这种分工感觉没有太大作用，以后理解更深刻的时候，再来详细分解（上图是改进后的MVVM，看着更合理）。
VIPER在cocoachina上看到的一篇文章，这个框架分层就更详细了，文章在此：使用VIPER构建iOS应用。
“VIPER 是一个创建 iOS 应用简明构架的程序。VIPER 可以是视图 (View)，交互器 (Interactor)，展示器 (Presenter)，实体 (Entity) 以及路由 (Routing) 的首字母缩写。简明架构将一个应用程序的逻辑结构划分为不同的责任层。这使得它更容易隔离依赖项 (如数据库)，也更容易测试各层间的边界处的交互：”
VIPER架构的重点：
交互器在应用中代表着一个独立的用例。它具有业务逻辑以操纵模型对象（实体）执行特定的任务。
实体是被交互器操作的模型对象，并且它们只被交互器所操作。交互器永远不会传输实体至表现层 (比如说展示器)。
展示器是一个主要包含了驱动用户界面的逻辑的 PONSO，它总是知道何时呈现用户界面。基于其收集来自用户交互的输入功能，它可以在合适的时候更新用户界面并向交互器发送请求。
视图一般是被动的，它通常等待展示器下发需要显示的内容，而不会向其索取数据。
路由：屏幕间的路径会在交互设计师创建的线框 (wireframes) 里进行定义。在 VIPER 中，路由是由两个部分来负责的：展示器和线框。一个线框对象包括 UIWindow，UINavigationController，UIViewController 等部分，它负责创建视图/视图控制器并将其装配到窗口中。
看完cocoachina的文章后，有点不懂的是路由的功能，可能是负责界面间的切换用的。
VIPER的结构大致如上面描述，但是感觉越来越像唐巧改进MVC后的结构，比如负责某个特定业务逻辑，和专门负责操作某个界面用的这几个功能跟改进后的MVC架构颇为相似。
所以最后的感觉是，所有架构都遵循一个原则：单一功能。将某些复杂的东西提取出来，比如请求、业务逻辑、界面逻辑、数据存储等，每个类负责单一的功能，最后使整个项目的复用率更高，效率更高。但是任何的结论都不是一定的，比如在界面展示和交互相对简单的项目中，分工越细，工作量反而越大。即使在一个项目中，比较简单的界面就可以怎么方便怎么来（个人理解）。
本文出自 “yunsankai” 博客，谢绝转载！
原文地址：http://yunsankai.blog.51cto.com/8376120/1751366
