注册 登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

重新出发的阿赵

阿赵的博客

 
 
 

日志

 
 

MVC设计模式的介绍  

2018-03-28 15:11:33|  分类: Unity教程 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

继续程序入门介绍系列,这次来说一下稍微复杂的东西

一、Unity项目使用框架有什么好处

以前有段时间我很喜欢在qq群里面回答问题,后来渐渐的也没太多时间回答了,所以变成了偶然看看别人讨论的过程。我后来发现,很多朋友都只是注重功能的实现,当实现了某个功能之后,就很高兴,觉得自己已经达到了一定的水平了。甚至有朋友直接的说,我能实现功能就够了,用Unity开发根本不需要用什么框架。

出现这种思想,我觉得有很大一部分原因是Unity官方造成的。因为Unity引擎在刚推出来的时候,宣传的是组件拼装的思想,而大部分demo都是针对某个具体功能展示而制作的。

所谓的组件拼装思想,就是我有一个空的GameObject,只带了最基本的Transform组件,可以控制位移旋转缩放。如果用户需要在上面添加功能,就可以添加相应的组件。比如我需要把一个空物体变成摄像机,只需要在空物体上面添加Camera组件,如果想这个摄像机同时有碰撞的功能,就再在上面加多个Collider碰撞组件,如果想这个物体顺便会发光,那就再添加一个Light的组件。假如需要更复杂的功能,可以自己写一个继承MonoBehaviour的脚本挂上去,因为MonoBehaviour脚本对于Unity来说也是一种组件。这样用户就可以抛弃面向对象的子类继承基类之类的繁琐结构,直接通过编辑器界面实现各种自由的功能。

所以,Unity引擎刚推出来的时候是偏向于给美术和策划用的,很多所见即所得的功能让你很简单就能实现想要的功能,很适合做规模较小的独立游戏。所以在这个阶段,Unity的确用不用框架好像没多大的区别。

但随着Unity的快速兴起,很多厂商开始拿Unity来做一些大型的项目。这个时候,很明显单一的功能实现已经不能满足项目的需要了。因为大型项目一般不会为某个功能的实现而发愁,更注重的是项目的清晰、易于维护和扩展等问题。由于有规模的项目都是多人协助一起写的,所以更需要注意项目代码的结构和质量。

好的代码标准,一般来说是高内聚,低耦合。我们需要把功能分离,让各人写的代码互不影响又能互相支持,可以单独的修改或者维护某一部分的代码而不影响到其他功能,代码可以重复利用,等等。为了达到这些目的,我们会使用一些设计模式,设计游戏的框架。

MVC是解决这个问题比较常见的一种设计模式,它不是一个具体的框架,而是一种设计的思想。可以根据这种设计的思想,写出适合项目用的框架。

二、MVC设计模式的特点

举一个稍微具体一点的例子来说明,我们现在需要做一个功能,可以在界面上面输入新增用户数据,然后列表显示出来。

如果是最简单的实现,我们可以只建立一个类,然后写代码实现三部分功能:

1、建立一个List来存储用户数据。

2、在类里面绘制一个显示列表来显示现有的用户数据,并绘制一个输入框和一个按钮来新增用户数据。

3、写一个添加用户数据的方法,把输入框的内容添加到用户数据的List

这样就把这个功能实现了。但假如我需要对需求做一些改变,比如我需要修改一下显示列表的位置和大小,或者我需要给数据存储加一个防止重复的功能,或者这个用户数据需要在其他功能也用到。在需求变动的情况下,这个类本身就需要不停的改变。等功能复杂到一定程度之后,这个类可能就会非常臃肿而难于维护了。

为了解决这个问题,我们可以尝试着把这个类拆分一下。

我们把一个类拆成三个类,分别是view类、model类和controller类。

view类里面写了现实列表的绘制方法,还有输入框和按钮的绘制。可以通过事件通知它数据改变而刷新界面上的数据显示。

model类里面写了用户数据的存储List,提供查询方法,还有数据变化时向外抛事件通知别人。

controller类里面写了按钮触发的方法,可以把view类输入的新增用户写到model里面。

 

这样分割了之后,某些功能相对的就稳定下来了。当我只需要调整界面外观时,我可以单独的修改view类,其他功能想使用用户数据,可以直接访问model类取得,而需要对操作过程加特殊的方法,只需要单独的修改controller类。另外一个好处是,这样在其他层面的逻辑还没写好之前,单独的层面就可以先编写。比如我还没确定这个界面样式是怎样摆放的,但我可以先把控制层和数据层写好,等显示界面层做好了之后,接入一下就行了。

MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写。一般的理解model层是数据的存储,view是界面的展示,controller是控制输入逻辑。

上面这个例子简单了介绍了MVC模式的工作原理,核心的思想就是,把功能分层,特别是把显示和数据分开,然后用另外一个层级让它们2个层级联合起来工作。

三、MVC模式的进化

MVC的确是现阶段广泛应用的一个设计模式,有很多使用这个模式写的框架。在使用过程中,会根据一些实际的情况去修改一些结构上的东西。

比如,MVC虽然是把功能分层了,但从最传统的MVC结构来说,View层是可以访问Model层的,比如View层可以直接去Model层查询数据并刷新自己的界面。这个时候,会发现三个层面是形成了一种三角的关系,有时候会存在需要同时维护三个层面的逻辑交互关系。

于是,后来MVC发展出了MVP(Model-View-Presenter)模式。这个模式里面,切断了Model层和View层的关联,view层只和Presenter层交互,再通过Presenter层和Model层交互。

这样,ModelView层就完全切断了关联,大部分的逻辑实现出现在Presenter层里面。而Presenter层通过向View层提供接口方法,实现了数据的查询和刷新等功能。这样做之后,当某个层面出现了修改的需要,他都只需要和Presenter层交互,所以不需要影响到另外一个层面。

MVC模式发展的另外一个方向,是MVVM(Model-View-ViewModel)。这里提出了一个叫做ViewModel的层面,一个View的类,一般会对应一个单独的ViewModel类,这个类完全为对应的View类服务,包括了View上面每一个显示数据的刷新显示、输入逻辑等等。然后ViewModel类再和Model类做交互。这样的情况下,在没有View类的情况下,ViewModel类已经完全可以实现了所有功能,只是没有把界面绘制出来而已。当有了View类,数据自然而然就会显示在界面上面了。

MVVM模式的2点比较突出的优点,第一是数据绑定,通过ViewModel层自动更新View层和Model层。第二是可以做界面功能的自动测试。因为在完全不需要显示View显示的情况下,通过调用ViewModel提供的各种接口,你等于已经完整的操作这个界面了。

四、一些个人看法

上面说了这么多MV什么的模式,估计都看懵了吧?实际上不管是MV什么,表达的核心思想都是一样的,显示层和数据层必须分离,然后第三层的作用都是用于沟通这两个层的。至于在实际应用中他们的关联交互程度应该具体怎样写,还是需要看你对这些设计模式的理解,还有你项目的具体需要。

对于新手来说,起码能有分层的概念,先可以看懂别人的框架结构。然后在使用别人的框架做功能的时候,可以根据分层的思想,把代码集中在对应的层面去编写。最后,在学习了现有的框架的写法之后,可以尝试着自己去写一些简单的框架,再一步一步的完事,就可以拥有一套属于自己的框架了。

  评论这张
 
阅读(230)| 评论(1)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018