首先说一下背景，这里的分享针对的是游戏项目客户端架构的设计。

逻辑分层意味着系统的组织结构划分规则与信息传递交互形态，明确各个层次主体，有助于降低系统的复杂度，决定了架构的可扩展性以及可维护性。

以下讨论的各种模型，本质是软件开发模式三层架构思想的实践，不同的业务场景和对三层模型思想的理解，创建的模型可谓五花八门，所以这里只是简单陈述一下个人在项目开发过程中的体会。

从学习（依葫芦画瓢）到自己总结出一种“更适合”的模型，个人主要经历了以下三个主要阶段。

PS：后来在网上搜索相关信息的时候，发现自己最后的心得也并不是什么开创性的工作，所以说类似的问题必然会有类似的解。

交互方式

1. Call – 直接调用
2. Callback – 委托回调
3. Message – 消息广播

不同的模型，对交互方式的影响是决定性的。在说到具体的模型实例之前，须先陈述一个观点，即从对象间依赖关系来看，简洁性与可读性的优先次序是：1>2>3。

模型实例

根据三层架构思想，Controller，Model，View三者的职能定义是非常清晰的。所以下面讲述的模型主要讨论的是三者之间的依赖关系。

一 MVC 1

坦白的说，这就是我对MVC的最原始理解。这里为了解决循环依赖的问题，Model与View的交互完全通过消息广播进行。

副作用：有的消息派发甚至仅有一个消息注册者，大量的消息广播，导致系统对象间的逻辑关系可读性非常差。

二 MVC 2

这种模型也被称为MVP（Model-View-Presenter）。类似命名，只能说从信息传播学的角度看是有意义的。

主要特点是做到了View和Model的完全隔离，减小了依赖对象的复杂度。

副作用：所有逻辑都部署在C这里，Controller会逐渐臃肿，一些编码只是做了View与Model的消息传递的工作，非常的形式化。

和前者不同，这里大量的消息广播变成了大量的委托回调。

三 MVC 3

这是最新理解的版本，规则如下：

1. View可读Model
2. View绝对禁止写Model
3. 写Model必须通过Controller

简单描述一下流程：Controller写完Model之后，通过事件通知View进行刷新，事件绝大多数情况下是不带参数的（参数解耦）。View响应刷新事件，并直接从Model读取数据。

从Model的角度来看，Model完全是”被动的“，既不依赖Controller，当然更不依赖View。生命周期和存续状态的更新完全由Controller控制。

这样解决了两大痛点：

1. 不需要消息广播（缺点上面已说过）
2. Controller层不需要为了View和Model的信息同步做一些只是转发的形式化工作

当不再为了解耦而解耦，故而有一种武侠高手“手中无剑”的感觉。