这里的mvc特指手游中的mvc。本文将从以下方面讨论手游客户端中mvc：分工，事件机制，依赖关系，实现细节，例子。
一 、分工
这里的mvc，m代表model(数据模型)，v代表view(界面)，c代表control(控制业务逻辑)。除此之外，mvc一般必须要实现的是事件机制或者观察者模式。
1．view的职责包括
a. 显示数据。这里的数据可以分为简单数据(不用处理的)和需要处理的数据。也可分为只显示一个系统的数据和显示多个系统的数据。这个在后面讨论到依赖关系和例子的时候，会详细说到。
b．更新显示的数据，通过监听事件。
c．接收玩家的输入，并将输入交给control进行处理。
成都网站建设、网站设计的开发，更需要了解用户，从用户角度来建设网站，获得较好的用户体验。
创新互联建站多年互联网经验，见的多，沟通容易、能帮助客户提出的运营建议。作为成都一家网络公司，打造的就是网站建设产品直销的概念。选择
创新互联建站，不只是建站，我们把建站作为产品，不断的更新、完善，让每位来访用户感受到浩方产品的价值服务。
- control的职责包括：
a．组织view上的数据。
b．接收view传过来的玩家输入，自己根据需求做必要的业务逻辑处理。这些业务逻辑包括弹出其他界面或者提示，更新某些界面(一般通过事件机制通知)，调用一个或多个model的方法进行各自的处理等。
c．control是作为一个中介者，即view和model不能有耦合，而是通过control这个中介者进行交互。 - model的职责包括：
a．保存数据。一般包括服务器的数据，和其他一些需要用到的数据。
b. 跟服务器进行通信，当服务器的信息有变化时，需要发送事件通知view或control。也有一些看法是要把这部分的逻辑放在control里面，但是我觉得这是跟数据密切相关的，所以应该放在model这里处理。
c. 根据control的输入(源自玩家的输入或者control处理过的数据)，做对应的逻辑，例如跟服务器通信或者根据需求更新自己的数据。
d．当数据变化的时候，要通知view或者control。
二、事件机制。
mvc中必须要实现的是事件机制或其他方式实现的观察者模式。事件机制使得mvc之间可以大大的解耦，因为发送事件的一方和接收事件的一方，完全不需要知道对方的存在。
- view 可以监听事件和发送事件。
- control 同样可以监听事件和发送事件。
- model 只可以发送事件。
三、依赖关系
mvc之间的依赖关系很少被文章或者人们谈论，也是大家往往不太注意的地方，但是这是及其重要的。
依赖关系的讨论包括：view与view，view与control，view与model，control与control，control与model，model与model。
- view与view。view与view之间不应该有任何的依赖关系。但是一个界面可以通过发送事件来通知另一个界面进行更新。
- view与control。一个view一般只会依赖于一个control，一个control可以被多个view依赖。
- view与model。虽然mvc的实质是，通过view去显示和更新model的数据，但是view和model之间不应该有依赖关系。对于简单数据(可直接用的)，view可通过自己依赖的control(control一开始可依赖一个model)上面的model引用，直接拿取该model里面的数据。对于需要处理的数据，一般都通过view所依赖的control的依赖方法来获取到自己想要的数据。
- control与control。control与control之间一般不要有依赖关系，就算有，也应该谨慎的考虑是否必要。
- control与model。control可依赖多个model，但是model不应该依赖于control。在某些情况下，一个view可能需要展示多个系统的数据或者与多个系统的数据进行交互，这个时候，可以新建一个新的control，这个control作为中介者与多个model进行交互。
- model与model。model绝对应该是独立的，model与model之间不应该有任何的依赖关系。
四、实现细节
- 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的方法。
- mvc之间的依赖关系尽量只依赖于名字，而不要依赖于具体的实例。以view和control之间的依赖举例。我见过的一些项目会这样处理他们的依赖关系。
这样的实现，就把依赖关系变为view的实例依赖于control的实例。这样的话，如果view的实现一样，只是需要依赖不同的Control，那么在重用的时候，可能需要复制一份同样的代码。比这个更好一点的处理方法是在构造函数里面指定自己的control实例：
这是一种比较的实现方式，当发生前面的那种情况的时候，只需要新建一个类继承这个类，然后重写setControl方法。
但是更好的处理方法应该是下面的这种，只依赖于名字：
这样，control的名字通过构造函数注入。当发上上面的需求的时候，只需要增加一个另外的view的配置即可。 - view的显示问题。view需要显示数据可分为：
a.简单数据(不用处理的)。对于这种情况，可以直接通过control的model引用来获取。例如componetA.text = myControl.model.dataA。
b.需要处理的数据(排序或者数据不能直接显示，需要转换)。这种情况会通过control的一个方法获取。例如componetA.text = myControl.getDataA()。
五、例子(手游中的成长系统)。
略。
完。
当前题目：关于手机游戏客户端中mvc框架的讨论-创新互联
文章起源：
http://cdkjz.cn/article/ieies.html
