首先，1.MVC，全称是：Model View Controller ，是模型、视图、控制器。是一种常见的客户端软件开发框架
在ios开发中，系统为我们实现好了公共的视图类：UIView,控制器：UIViewController。大多数时候我们都需要集成这些类实现程序逻辑；MVC 这种分层方式虽然清楚，但是如果使用不当，很可能让大量代码都集中在 Controller 之中，让 MVC 模式变成了 Massive View Controller 模式。
Controller的臃肿问题
其实设计模式喝多时候是为了Don't repeat yourself 原则来做的，该原则要求能够重复的代码要金狼服用，来保证重用。在MVC这种设计模式中，我们发现View和model都是符合这种原则
对于View来说，视图仅仅是展示给用的界面视图，一个视图的展示，我们来单独封装一个类，向外边提供接口，供Controller使用
对于Model，把不规则的数据源，进过model 统一处理成规则的model，什么空字符，null，都要在model中处理
Controller，这种很少可以复用，我们可能可以用addSubViewController之类的方式复用 Controller，但它的复用场景还是非常非常少的。
如果我们能够意识到 Controller 里面的代码不便于复用，我们就能知道什么代码应该写在 Controller 里面了，那就是那些不能复用的代码。在我看来，Controller 里面就只应该存放这些不能复用的代码，这些代码包括：
在初始化时，构造相应的 View 和 Model。
监听 Model 层的事件，将 Model 层的数据传递到 View 层。
监听 View 层的事件，并且将 View 层的事件转发到 Model 层。
如果 Controller 只有以上的这些代码，那么它的逻辑将非常简单，而且也会非常短。
但是，我们却很难做到这一点，因为还是有很多逻辑我们不知道写在哪里，于是就都写到了 Controller 中了，那我们接下来就看看其它逻辑应该写在哪里。但是但是，我突然想到，我们好象只需要一个 ViewModel 而已，我完全可以简单地做一个 ViewModel 的工厂类或 Service 类就可以了，为什么要引入这么多框架？现有的 MVC 真的有那么大的问题吗？
MVVM 的作用和问题
MVVM是 Model-View-ViewModel 的简写。
相对于 MVC 的历史来说，MVVM 是一个相当新的架构，MVVM 最早于 2005 年被微软的 WPF 和 Silverlight
的架构师 John Gossman 提出，并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了，可见两者出现的年代差别有多大。
MVVM 在使用当中，通常还会利用双向绑定技术，使得 Model 变化时，ViewModel 会自动更新，而 ViewModel 变化时，View 也会自动变化。所以，MVVM 模式有些时候又被称作：model-view-binder模式。
具体在 iOS 中，可以使用 KVO 或 Notification 技术达到这种效果。
MVVM 在实际使用中，确实能够使得 Model 层和 View 层解耦，但是如果你需要实现 MVVM 中的双向绑定的话，那么通常就需要引入更多复杂的框架来实现了。
对此，MVVM 的作者 John Gossman 的批评应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点：
第一点：数据绑定使得 Bug 很难被调试。你看到界面异常了，有可能是你 View 的代码有 Bug，也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置，要定位原始出问题的地方就变得不那么容易了。
第二点：对于过大的项目，数据绑定需要花费更多的内存。
某种意义上来说，我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是，这个缺点同时也被很多人认为是优点。
