iOS中的MVC设计模式

Model-View-Controller(模型-视图-控制器，MVC) 模式将你的软件组织并分解成三个截然不同的角色：

• Model 封装了你的应用数据、应用流程和业务逻辑。

• View 从 Model 获取数据并格式化数据以进行显示。

• Controller 控制程序流程，接收输入，并把它们传递给 Model 和 View。

与其它设计模式不同，MVC 模式并没有直接反映一个你能够编写或配置的类结构。相反，MVC 更像一个概念上的指导原则或范型。概念上的 MVC 模式被描述为三个对象 —— Model、View 和 Controller —— 之间的关系。由于 View 和 Controller 都可以从 Model 请求数据，所以 Controller 和 View 都依赖 Model。任何输入都通过 Controller 进入你的系统，然后 Controller 选择一个 View 来发出结果。

  涉及到的三个角色如下：

              1. Model:

Model 包含了你的应用逻辑和数据，在你的应用程序中，它很可能是主要的值驱动器。Model 没有任何与表现层相关的特性，而且也和 HTTP 请求处理职责中完全无关。

当需要本地储存的时候Model也可以是是数据库模型:

（1）创建数据库、创建相应的表

（2）完成针对数据库各个表的增、删、改、查的操作类

（3）映射数据库各个表的实体类（这个实体类的作用就是沟通数据库层（Model）和控制层（Controller）的桥梁，同时这个实体类也将担负其后台数据（xml、sbjson等）与本地数据的沟通和存储）

        2.  View:  

视图是模型的可视化表示以及用户交互的控件；基本上来说，所有的UIView 对象以及它的子类都属于视图。在本应用中AlbumView 代表了视图。

      3.   Controller:

 控制器 (ViewController)是一个协调所有工作的中介者（Mediator ）。它访问模型中的数据并在视图中展示它们，同时它们还监听事件和根据需要操作数据。

这个层的意义就在于确保M和V的同步。这层不仅叫控制层，更应该叫业务层。

　　本层要实现的功能：

　　    (1) 本层输入件：界面控件中数据和事件

　 　(2) 本层输出件：

　 　 第一：调用M层的接口，更新Model层（数据库）中的数据

　 　 第二：调用V层的接口，更新View层（界面）中的数据

一个 MVC 模式的好的实现也就意味着每一个对象都会被划分到上面所说的组中。

      我们可以很好的用下图来描述通过控制器实现的视图到模型的交互过程：

 

   

模型会把任何数据的变更通知控制器，然后控制器更新视图数据。视图对象通知控制器用户的操作，控制器要么根据需要来更新模型，要么检索任何被请求的数据。

      你可能在想为什么不能仅仅使用控制器，在一个类中实现视图和模型，这样貌似更加容易 ? 

      所有的这些都归结于代码关注点分离以及复用。在理想的状态下，视图应该和模型完全的分离。如果视图不依赖某个实际的模型，那么视图就可以被复用来展示不同模型的数据。

      举个例子来说，如果将来你打算加入电影或者书籍到你的资料库中，你仍然可以使用同样的 AlbumView 去显示电影和书籍数据。更进一步来说，如果你想创建一个新的与专辑有关联的工程，你可以很简单的复用 Album 类，因为它不依赖任何视图。这就是 MVC 的强大之处。

如何使用MVC模式

首先，你需要确保在你工程中的每个类是控制器，模型和视图中的一种，不要在一个类中组合两种角色的功能。到目前为止，你创建了一个 Album 类和 AlbumView 类，这样做挺好的。

其次，为了确保你能符合这种工作方法，你应该创建三个工程组（ Project Group ）来保存你的代码，每个工程组只存放一种类型的代码。

 

 

显然你也可以有其它的组和类，但是本应用的核心包含在这三个类别中（ Model,View,Controller ）。

总结

使用MVC模式可以达到帮VC瘦身，可以到到提高复用性和可维护性的效果，同时也会让原本一个整体的业务代码，分散到各个不同的地方。实际使用中我们需要具体问题具体分析，如果一个VC中的东西本身就很简单，那么完全可以放在一起，因为即使全部放在一起也就几百行代码。例如App中常见的Copyright界面，本身就是加载一个html就搞定了，就完全没必要搞得那么复杂；如果一个VC已经很复杂，代码动辄几千行了，那么就需要拆分，达到更好的复用以及方便维护的目的。

看过很多的代码了，见过所有东西都往一个源文件里面塞的，也见过一个本就很简单的东西被设计模式搞的四分五裂的，不要为了用设计模式而用设计模式。把握好度很重要，能用子弹解决的问题就不要动大炮。

代码重构应该是一个持久的过程，在开发的过程中就时不时的对现有不合理的地方进行重构，而不是等待问题已经很多了才想起重构来。千里之行始于足下，千里之堤溃于蚁穴。