MVC设计模式 MVVM设计模式

MVC模式：

     模型-视图-控制器（Model-View-Controller，MVC）是Xerox PARC在20世纪80年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已广泛应用于用户交互应用程序中。在iOS开发中MVC的机制被使用的淋漓尽致，充分理解iOS的MVC模式，有助于我们程序的组织合理性。

 

• 模型对象

     模型对象封装了应用程序的数据，并定义操控和处理该数据的逻辑和运算。例如，模型对象可能是表示游戏中的角色或地址簿中的联系人。用户在视图层中所进行的创建或修改数据的操作，通过控制器对象传达出去，最终会创建或更新模型对象。模型对象更改时（例如通过网络连接接收到新数据），它通知控制器对象，控制器对象更新相应的视图对象

• 视图对象

     视图对象是应用程序中用户可以看见的对象。视图对象知道如何将自己绘制出来，并可能对用户的操作作出响应。视图对象的主要目的，就是显示来自应用程序模型对象的数据，并使该数据可被编辑。尽管如此，在 MVC 应用程序中，视图对象通常与模型对象分离。

• 控制器对象

      在应用程序的一个或多个视图对象和一个或多个模型对象之间，控制器对象充当媒介。控制器对象因此是同步管道程序，通过它，视图对象了解模型对象的更改，反之亦然。控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。

      控制器对象解释在视图对象中进行的用户操作，并将新的或更改过的数据传达给模型对象。模型对象更改时，一个控制器对象会将新的模型数据传达给视图对象，以便视图对象可以显示它。

      对于不同的UIView，有相应的UIViewController，对应MVC中的C。例如在iOS上常用的UITableView，它所对应的Controller就是UITableViewController。

1. Model和View永远不能相互通信，只能通过Controller传递。
2. Controller可以直接与Model对话（读写调用Model），Model通过Notification和KVO机制与Controller间接通信。
3. Controller可以直接与View对话，通过outlet,直接操作View,outlet直接对应到View中的控件,View通过action向Controller报告事件的发生(如用户Touch我了)。Controller是View的直接数据源（数据很可能是Controller从Model中取得并经过加工了）。Controller是View的代理（delegate),以同步View与Controller。

MVVM设计模式：

      MVVM，Model-View-ViewModel，一个从 MVC 模式中进化而来的设计模式，最早于2005年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出。在 iOS 开发中实践 MVVM 的话，通常会把大量原来放在 ViewController 里的视图逻辑和数据逻辑移到 ViewModel 里，从而有效的减轻了 ViewController 的负担。另外通过分离出来的 ViewModel 获得了更好的测试性，我们可以针对 ViewModel 来测试，解决了界面元素难于测试的问题。MVVM 通常还会和一个强大的绑定机制一同工作，一旦 ViewModel 所对应的 Model 发生变化时，ViewModel 的属性也会发生变化，而相对应的 View 也随即产生变化。

• model:  数据模型
• View：主要用于界面和显示（封装的一些常用的View控件）
• ViewModel：相比较于MVC新引入的视图模型。是视图显示逻辑、验证逻辑、网络请求等代码存放的地方，唯一要注意的是，任何视图本身的引用都不应该放在VM中，换句话说就是VM中不要引入UIKit.h (对于image这个，也有人将其看做数据来处理，这就看个人想法了，并不影响整体的架构)。
• ViewControllers： 界面控制器

使用MVVM架构最大的好处是:开发人员在写程序的时候不需要做UI。

主要的好处如下:

1. 低耦合。视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时候Model不可以不变，当Model变化的时候View也可以不变。
2. 可重用性。你可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
3. 独立开发。开发人员可以专注于业务逻辑和数据的开发（ViewModel），设计人员可以专注于页面设计，使用Expression Blend可以很容易设计界面并生成xaml代码。
4. 可测试。界面素来是比较难于测试的，而现在测试可以针对ViewModel来写。

同样的，MVVM 也有他的缺点：

• 一个首要的缺点是，MVVM 的学习成本和开发成本都很高。MVVM 是一个年轻的设计模式，大多数人对他的了解都不如 MVC 熟悉，基于绑定机制来进行编程需要一定的学习才能较好的上手。同时在 iOS 客户端开发中，并没有现成的绑定机制可以使用，要么使用 KVO，要么引入类似 ReactiveCocoa 这样的第三方库，使得学习成本和开发成本进一步提高。
• 另一个缺点是，数据绑定使 Debug 变得更难了。数据绑定使程序异常能快速的传递到其他位置，在界面上发现的 Bug 有可能是由 ViewModel 造成的，也有可能是由 Model 层造成的，传递链越长，对 Bug 的定位就越困难。
• 同时还必须指出的是，在传统的 MVVM 架构中，ViewModel 依然承载的大量的逻辑，包括业务逻辑，界面逻辑，数据存储和网络相关，使得 ViewModel 仍然有可能变得和 MVC 中 ViewController 一样臃肿。