作为一个iOS程序员，MVC一定是我们耳熟能详的一种架构模式，而且当你的项目规模不大的时候，MVC也确实有它的优势，它的开发效率确实是足够高。但当你的项目发展的一定的规模，你会发现传统的MVC模式会导致C层代码量剧增，维护困难等一系列问题，这个时候我们就需要考虑一些其它模式了。

MV(X)的基本要素

常用的架构模式

• MVC
• MVVM
• MVP
• VIPER

前面三种模式都由三个模块组成：

• Models —— 数据层，负责数据的处理。
• Views —— 展示层，即所有的UI
• Controller/Presenter/ViewModele（控制器/展示器/视图模型）——它们负责View与Mode之间的调配

MVC

传统的MVC

我们所熟知的MVC其实Apple给我们提供的Cocoa MVC，但其实MVC最先产生于Web，它原来的样子应该是这样的

在这种架构下，View是无状态的，在Model变化的时候它只是简单的被Controller重绘，比如网页中你点击了一个新的链接，整个页面就重新加载。尽管这种MVC在iOS应该里面可以实现，但是由于MVC的三个模块都紧密耦合了，每一个模块都和其它两种模块有联系，所以即便是实现了也没有什么意义。这种耦合还降低了它们的可重用性，所以，传统的MVC在iOS中可以舍弃了。

Apple提供的MVC中，View和Model之间是相互独立的，它们只通过Controller来相互联系。可惜的是Controller得重用性太差，因为我们一般都把冗杂的业务逻辑放在了Controller中。

现实中，我们的MVC一般是这样的

为什么会这样呢？主要还是因为我们的UIViewController它本身就拥有一个VIew，这个View是所有视图的根视图，而且View的生命周期也都由Controoler负责管理，所以View和Controller是很难做到相互独立的。虽然你可以把控制器里的一些业务逻辑和数据转换工作交给Model，但是你却没有办法将一些工作让View来分摊，因为View的主要职责只是将用户的操作行为交给Controller去处理而已。于是Controller最终就变成了所有东西的代理和数据源，甚至还有网络请求.....还有......所以我们写的Controller代码量一般都是非常大的，随着当业务需求的增加，Controller的代码量会一直增长，而相对来说View和Model的代码量就比较稳定，所以也有人把MVC叫做Massive View Controller，因为Controller确实显得有些臃肿。

在这里关于Model的划分，其实有一个胖Model和瘦Model之分，它们的差别主要就是把Controller的部分数据处理职责交给了胖Model。

胖Model（Fat Model）：

胖Model包含了部分弱业务逻辑。胖Model要达到的目的是，Controller从胖Model这里拿到数据之后，不用做额外的操作或者只做非常少的操作就能将数据应用在View上。
FatModel做了这些弱业务之后，Controller可以变得相对skinny一点，它只需要关注强业务代码。而强业务变动的可能性要比弱业务大得多，弱业务相对稳定，所以弱业务塞给Model不会有太大问题。另一方面，弱业务重复出现的频率要大于强业务，对复用性要求更高，如果这部分业务写在Controller，会造成代码冗余，类似的代码会洒得到处都是，而且一旦弱业务有修改，你就会需要修改所有地方。如果塞到了Model中，就只需要改Model就够了。
但是胖Mpdel也不是就是没有缺点的，它的缺点就在于胖Model相对比较难移植，虽然只是包含弱业务，但是它毕竟也是业务，迁移的时候很容易拔出罗布带出泥，也就是说它耦合了它的业务。而且软件是会成长的，FatModel也很有可能随着软件的成长越来越Fat，最后难以维护。

瘦Model（Slim Model）：

瘦Model只负责业务数据的表达，所有业务无论强弱一律人给Controller。瘦Model要达到的目的是，尽一切可能去编写细粒度Model，然后配套各种helper类或者方法来对弱业务做抽象，强业务依旧交给Controller。
由于Slim Model跟业务完全无关，它的数据可以交给任何一个能处理它数据的Helper或其他的对象，来完成业务。在代码迁移的时候独立性很强，很少会出现拔出萝卜带出泥的情况。另外，由于SlimModel只是数据表达，对它进行维护基本上是0成本，软件膨胀得再厉害，SlimModel也不会大到哪儿去。缺点就在于，Helper这种做法也不见得很好，由于Model的操作会出现在各种地方，SlimModel很容易出现代码重复，在一定程度上违背了DRY（Don’t Repeat Yourself）的思路，Controller仍然不可避免在一定程度上出现代码膨胀。

综上所述，Cocoa MVC在各方面的表现如下：

• 划分 - View 和 Model 确实是实现了分离，但是 View 和 Controller 耦合的太 厉害
• 可测性 - 因为划分的不够清楚，所以能测的基本就只有 Model 而已
• 易用 - 相较于其他模式，它的代码量最少。而且基本上每个人都很熟悉它，即便是没太多经验的开发者也能维护。

MVP