关于手机游戏客户端中mvc框架的讨论-创新互联

这里的mvc特指手游中的mvc。本文将从以下方面讨论手游客户端中mvc:分工,事件机制,依赖关系,实现细节,例子。
一 、分工
这里的mvc,m代表model(数据模型),v代表view(界面),c代表control(控制业务逻辑)。除此之外,mvc一般必须要实现的是事件机制或者观察者模式。
1.view的职责包括
a. 显示数据。这里的数据可以分为简单数据(不用处理的)和需要处理的数据。也可分为只显示一个系统的数据和显示多个系统的数据。这个在后面讨论到依赖关系和例子的时候,会详细说到。
b.更新显示的数据,通过监听事件。
c.接收玩家的输入,并将输入交给control进行处理。

成都网站建设、网站设计的开发,更需要了解用户,从用户角度来建设网站,获得较好的用户体验。创新互联建站多年互联网经验,见的多,沟通容易、能帮助客户提出的运营建议。作为成都一家网络公司,打造的就是网站建设产品直销的概念。选择创新互联建站,不只是建站,我们把建站作为产品,不断的更新、完善,让每位来访用户感受到浩方产品的价值服务。
  1. control的职责包括:
    a.组织view上的数据。
    b.接收view传过来的玩家输入,自己根据需求做必要的业务逻辑处理。这些业务逻辑包括弹出其他界面或者提示,更新某些界面(一般通过事件机制通知),调用一个或多个model的方法进行各自的处理等。
    c.control是作为一个中介者,即view和model不能有耦合,而是通过control这个中介者进行交互。
  2. model的职责包括:
    a.保存数据。一般包括服务器的数据,和其他一些需要用到的数据。
    b. 跟服务器进行通信,当服务器的信息有变化时,需要发送事件通知view或control。也有一些看法是要把这部分的逻辑放在control里面,但是我觉得这是跟数据密切相关的,所以应该放在model这里处理。
    c. 根据control的输入(源自玩家的输入或者control处理过的数据),做对应的逻辑,例如跟服务器通信或者根据需求更新自己的数据。
    d.当数据变化的时候,要通知view或者control。

二、事件机制。
mvc中必须要实现的是事件机制或其他方式实现的观察者模式。事件机制使得mvc之间可以大大的解耦,因为发送事件的一方和接收事件的一方,完全不需要知道对方的存在。

  1. view 可以监听事件和发送事件。
  2. control 同样可以监听事件和发送事件。
  3. model 只可以发送事件。

三、依赖关系
mvc之间的依赖关系很少被文章或者人们谈论,也是大家往往不太注意的地方,但是这是及其重要的。
依赖关系的讨论包括:view与view,view与control,view与model,control与control,control与model,model与model。

  1. view与view。view与view之间不应该有任何的依赖关系。但是一个界面可以通过发送事件来通知另一个界面进行更新。
  2. view与control。一个view一般只会依赖于一个control,一个control可以被多个view依赖。
  3. view与model。虽然mvc的实质是,通过view去显示和更新model的数据,但是view和model之间不应该有依赖关系。对于简单数据(可直接用的),view可通过自己依赖的control(control一开始可依赖一个model)上面的model引用,直接拿取该model里面的数据。对于需要处理的数据,一般都通过view所依赖的control的依赖方法来获取到自己想要的数据。
  4. control与control。control与control之间一般不要有依赖关系,就算有,也应该谨慎的考虑是否必要。
  5. control与model。control可依赖多个model,但是model不应该依赖于control。在某些情况下,一个view可能需要展示多个系统的数据或者与多个系统的数据进行交互,这个时候,可以新建一个新的control,这个control作为中介者与多个model进行交互。
  6. model与model。model绝对应该是独立的,model与model之间不应该有任何的依赖关系。

四、实现细节

  1. view用ViewManager管理起来,ViewManager要保存一个字典,key是view的名字,value是view的实例。control用ControlManager管理起来,ControlManager要保存一个字典,key是control的名字,value是control的实例。model用ModelManager管理起来,ModelManager要保存一个字典,key是model的名字,value是model的实例。ViewManager、ControlManager、ModelManager可以再通过外观模式进行进一步的封装,即规定系统不直接调用ViewManager、ControlManger、ModelManager的接口,而只能调用他们的外观类App的方法。
  2. mvc之间的依赖关系尽量只依赖于名字,而不要依赖于具体的实例。以view和control之间的依赖举例。我见过的一些项目会这样处理他们的依赖关系。
    关于手机游戏客户端中mvc框架的讨论
    这样的实现,就把依赖关系变为view的实例依赖于control的实例。这样的话,如果view的实现一样,只是需要依赖不同的Control,那么在重用的时候,可能需要复制一份同样的代码。比这个更好一点的处理方法是在构造函数里面指定自己的control实例:
    关于手机游戏客户端中mvc框架的讨论
    这是一种比较的实现方式,当发生前面的那种情况的时候,只需要新建一个类继承这个类,然后重写setControl方法。
    但是更好的处理方法应该是下面的这种,只依赖于名字:
    关于手机游戏客户端中mvc框架的讨论
    这样,control的名字通过构造函数注入。当发上上面的需求的时候,只需要增加一个另外的view的配置即可。
  3. view的显示问题。view需要显示数据可分为:
    a.简单数据(不用处理的)。对于这种情况,可以直接通过control的model引用来获取。例如componetA.text = myControl.model.dataA。
    b.需要处理的数据(排序或者数据不能直接显示,需要转换)。这种情况会通过control的一个方法获取。例如componetA.text = myControl.getDataA()。

五、例子(手游中的成长系统)。
略。

完。


名称栏目:关于手机游戏客户端中mvc框架的讨论-创新互联
网页地址:http://cdiso.cn/article/ieies.html

其他资讯