移动开发中MVC模式和分层

MVC在界面开发中被奉为设计的典范,在移动开发中也是

MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写。

它将业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑聚集到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。


我刚接触ios,想通过ios的一些实例设计来理解MVC在ios中的应用。

1. IOS的view

对于工具化的图形界面设计,这个就应该是各种视图控件的设计,页面和控件的大小、位置、边框、颜色(前景、背景)、字体、title等属性的设置。

对于定制化的图形界面,仍然需要代码来设计页面和控件的大小、位置、边框、颜色(前景、背景)、字体、titile等属性。

UIView是ios视图设计中,最基本的一个类。里面很多属性需要定义。


与view紧密关联的数据就是viewcontroller了,view的刷新和输入提交都是通过controller来完成。

controller对view拥有控制权,简单来说,一个controller拥有访问其view实体的权利。


controller会拥有哪些权利? 这就是controller与view不同的地方,代码相分离的地方。


2. iOS的controller

controller面对view的功能有:

能显示的修改view中的关联变量,驱动view的刷新。

能保存view中的关联变量,驱动model数据在服务端或cache的更新。


为实现一个完整的feature:

controller一般还拥有一些功能,如:

1. 逻辑处理、数据处理、错误处理等等

2. 与其他controller的交互

3. 访问server

4. 访问数据库

由以上功能来看,controller还能再分几层, 如逻辑层,cache层,server api call层(如rest)。


3. ios的Model

controller中使用的数据结构的定义。
Model的定义一般仅仅是POJO模式,定义一个对象的成员变量的 getter, setter函数。或者再增加一些通用的数据处理,如toJson, fromJson等

没有业务逻辑,是一个简单的实体类。

这个model一般与server protocol协议和数据库表 密切相关。

MVC的结构图
技术分享


一些实践经验:
1. data model与server的protocol最好能分离。
一般情况下,data model可以与protocol共用一套数据结构。但这样的耦合会很不方便,protocol的变化会频繁影响到data model, 特别是类似json,和hibernate之类的变量名与资源和较强的关联关系时。

data model可以大而全,与protocol保持一定关联,但又能灵活分离。

所以,可以有一个data model模块,和一个 protocol模块。
当协议频繁改动时,旧协议可以不改变, data model也能做到适应新协议,并兼容老协议。

2. 移动端的data model的演化,字段的删除、增加都可以,但最好去除容易混淆的字段、重复意义的字段。
同一data model中,当不同业务各自的字段时,尽量去统一起来,可以由server端来维护和兼容新老协议。

3. 每个rest api call的protocol保持最小化,便于传输,功能分离等,并且保持一定的可扩展性。
对于最小化,将空对象null,空数组[],在传输过程中过滤,并且对于protocol尽量不复用现有的嵌套对象,这样会令人confusing,会有很多深层嵌套和空白字段。

对于可扩展性,如 增加{}嵌套,便于扩展新的对象。




郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。