iOS开发之理解iOS中的MVC设计模式

iOS开发之理解iOS中的MVC设计模式

柳志超博客 » Program » IOS » iOS开发之理解iOS中的MVC设计模式

posted in IOS on 2013/01/03 by liuzc

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

模型对象
模型对象封装了应用程序的数据，并定义操控和处理该数据的逻辑和运算。例如，模型对象可能是表示游戏中的角色或地址簿中的联系人。用户在视图层中所进行的创建或修改数据的操作，通过控制器对象传达出去，最终会创建或更新模型对象。模型对象更改时（例如通过网络连接接收到新数据），它通知控制器对象，控制器对象更新相应的视图对象。
视图对象
视图对象是应用程序中用户可以看见的对象。视图对象知道如何将自己绘制出来，并可能对用户的操作作出响应。视图对象的主要目的，就是显示来自应用程序模型对象的数据，并使该数据可被编辑。尽管如此，在 MVC 应用程序中，视图对象通常与模型对象分离。

在iOS应用程序开发中，所有的控件、窗口等都继承自 UIView，对应MVC中的V。UIView及其子类主要负责UI的实现，而UIView所产生的事件都可以采用委托的方式，交给UIViewController实现。
控制器对象
在应用程序的一个或多个视图对象和一个或多个模型对象之间，控制器对象充当媒介。控制器对象因此是同步管道程序，通过它，视图对象了解模型对象的更改，反之亦然。控制器对象还可以为应用程序执行设置和协调任务，并管理其他对象的生命周期。

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

对于不同的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。

 

有关“模型－视图－控制器”的完整信息，请参阅 Concepts in Objective-C Programming（Objective-C 编程中的概念）中的：Model-View-Controller

 

浅析iOS程序设计模式（基于MVC）

 

接触iOS手机开发有一段时间了。总体来说，苹果公司设计的开发环境还是非常人性化的。很容易上手，也方便深入。

       在组织大型项目的代码文件时，我们常用MVC的思想。MVC的概念讲起来非常简单，就和对象（object）一样。但是理解和应用起来却非常困难。今天我们就试着探讨一下MVC设计理念。

       M是指业务模型，V是指用户界面，C则是控制器，使用MVC的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。

       比如一批统计数据可以分别用柱状图、饼图来表示。

       C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。

 

    　再实际开发中，M虽然本意是业务模型，但通常被理解为数据库操作层。

　　V即界面层，这个没有异议。

　　C则被理解为业务层。

　　对应在ios中，V就是指.xib文件。C是指.m文件。但是，通常情况并不如我们想像的这么理想。因为客户的需求是千变万化的。很多时候，我们需要根据客户的需求对界面进行自定义。所以，很多时候界面代码和会混淆在.m文件中和控制层代码掺杂在一起。

 

　　在我个人的设想中，MVC这三层分别要完成哪些工作呢？

1、M层 模型（更多的是数据库模型）

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

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

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

 

　　本层要实现的功能：

　　（1）

　　本层输入件：sql增加或插入数据库表对应的实体类的对象的语句

　　本层输出件：增加、或插入数据库

　　（2）

　　本层输入件：sql查询语句

　　本层输出件：返回存储实体类对象的数组

　　（3）

　　本层输入件：sql删除语句

　　本层输出件：删除数据库中的指定信息

 

2、V层 视图

不用多讲了，在ios中，这个层主要由.xib文件完成。如果客户由自定义需求，则在.m文件中实现。

本层实现的功能就是控件的布局。

 

3、C层 控制

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

　　本层要实现的功能：

　　（1）

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

　　本层输出件：

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

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

 

 

　　在现实的开发过程中，代码真的就这么清晰地分成以上三种吗？

　　现实中，工程中还有以下几种类型的代码：

　　（1）接口文件［数据操作］

　　（2）解析通过接口获取的数据［数据操作］

　　（3）开源框架（实现各种界面效果、解析各种数据）［数据操作＋V显示］

　　（4）工具类（比如为图片增加圆角、实现checkbox、实现各种页面效果、数据加密解密）[数据操作＋V显示]

　　（5）本项目提炼的公用类（如验证、升级检测、数据更新等）［数据操作M］

 

 

业务层BusinessLayer：

可以调用：数据层

可以被调用：控制层

 

组织当前软件独特的业务体系，只处理数据，和数据层和控制层有关系，和界面层没有任何关系。

常见业务：

（1）数据同步（用到数据层数据操作和界面层的数据）

（2）软件升级

（3）登录验证

（4）账号有效性验证

 

　　控制层ControllerLayer：只负责数据层和界面层的数据同步（通过业务层来实现）

　　数据层DataLayer:只和数据打交道，和业务毫无关系

　　界面层ViewLevel：只和界面打交道，和控制层打交道，和其他层毫无关系

上面写的比较乱，来张图，看看能不能捋清楚，知道我们在实际编码过程中组织各种代码和文件：

 

用MVC思想重构一个项目的核心就是剥离出这个项目的业务逻辑。

什么是项目的业务逻辑？所谓业务逻辑关注点主要集中在业务规则的制定、业务流程的实现等与业务需求有关的系统设计。简而言之，所谓业务逻辑就是指业务规则。凡事有规则的东西，就是业务逻辑，没有规则的东西就不是业务逻辑。

 

利用MVC思想组织的文件结构一例：

 

参考：

用自己的话讲对mvc的理解，直观   http://hi.baidu.com/javvinnet/item/c231542073c3f851c38d5944

对mvc专业的解释：                   http://www.cnblogs.com/shanyou/archive/2010/04/03/1703501.html

三层开发  http://baike.baidu.com/link?url=9eOHD-1z9BUIxInOTlj4yna0KRILwQNXkPa-4LEPZhfjIoBzjyx6e6Au3SEvW-eqANLCTFVgqTtYMPbAhZRh2K

转载于:https://www.cnblogs.com/lvyinbentengzhe/p/4224443.html