移动开发之iOS基础开发（五）iOS开发中的MVC设计实现

使用MVC的目的是将模型和视图的实现代码分离，从而使同一个程序可以使用不同的表现形式。那么MVC具体指的都是那些呢？

1. 模型层（Model）：该层次完成的主要工作是业务流程/状态的处理以及业务规则的制定。
2. 视图层（View）：视图即为用户交互界面，视图接受来自模型的数据，并予以展示。
3. 控制器（Controller）：控制器主要负责从用户接受请求，并将模型与视图整合在一起，共同完成相关任务。控制层本身不做任何的数据处理。例如用户点击一个链接，控制层接受请求后，并不处理业务信息，只是把用户的信息传递给模型，告诉模型应该做什么，然后选择符合要求的视图返回给用户。所以，一个模型可能对应多个视图，一个视图也可能对应多个模型。

一、MVC的优点：MVC要求应用分层，虽然会增加额外的工作，但产品的结构清晰，其应用通过模型可以得到更好的表现，具体表现如下：

1. 具有多个视图对应一个模型的能力。例如订单模型可能有本系统的订单，也有网上订单，或者其他系统的订单，不管是哪种，对订单的处理是一样的，也就是说对叮当的处理是一致的。按MVC设计模式，一个订单模型及多个视图即可解决问题。这样既减少了代码的重复，又减少了代码的维护量，一旦模型发生改变，也易于维护。
2. 由于模型返回的数据不带任何显示格式，为此这些模型也可直接应用于接口。
3. 由于一个应用被分离为三层，因此有时仅改变其中的一层就能满足应用的变化。当应用的业务流程或者业务规则改变时只需改动MVC中的模型层，其他两层可保持不变。
4. 由于控制层是把不同的模型和不同的视图组合在一起完成不同的请求，因此，控制层可以说是包含了用户请求权限的概念。
5. MVC模式有利于软件工程化管理。由于不同的层各司其职，每一层的不同应用间具有某些相同的特征，有利于通过工程化，工具化产生管理程序的代码。

二、MVC的缺点：

1. 增加了系统结构和实现的复杂性。对于简单的界面。如果严格遵循MVC模式，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。
2. 视图与控制器的联系仍过于紧密，视图与控制器是既相互分离又确实联系紧密的部件，没有控制器，视图的应用会很有限，反之亦然。这样妨碍了他们的独立重用。
3. 视图对模型数据的访问效率比较低。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据，对为变化的不必要的频繁访问，也降低了操作性能。

三、iOS中的MVC

视图组件由UIView类的子类及其相关的UIViewController类来提供。控制器行为通过三种关键技术来实现，分别是委托，目标操作和通知；模型方法通过数据库和数据含义等协议提供数据，同时需要由控制器触发的回调方法。

从MVC三大组成部分的分工来看，模型部分定义应用程序的数据引擎，负责维护数据的完整性；视图部分定义应用程序的用户界面，对显示在用户界面上的数据出处则没有清楚的认识；控制器部分则从当模型和视图的桥梁，帮助实现数据的显示与更新。

MVC设计过程中，应遵循以下规则：

1. Model和View永远不能相互通信，只能通过Controller来传递。
2. Controller可以直接与Model对话（读写Model），Model通过Notification和KVO机制与Controller通信。
3. Controller可以直接与View对话，View通过action向Controller报告事件的发生。Controller是View的直接数据源（数据很可能是Controller从Model取得）。Controller是View的代理（delegate），以同步View与Controller。

iOS开发中，所有的控件、窗口等都继承自UIView，对应MVC中的V。UIView及其子类主要负责UI的实现，而UIView所产生的事件都可以采用委托的方式，交给UIViewController实现。对于不同的UIView，对应的UIViewCOntroller相当于MVC中的C。例如常用的UITableView对应的Controller就是UITableViewController。至于MVC中的M，需要用户自己的需求来定义实现了