AS3 前端网页游戏系统的开发

目录

1      
前端（系统）功能的框架结构... 1

2      
配表数据的读取... 3

2.1       
配表管理类的创建与规范... 3

2.2       
Tab配表数据的读取... 3

2.3       
Xml配表数据的读取... 3

2.4       
数据管理类的规范与建议... 3

3      
数据模型的存储与通信... 3

3.1       
模型的创建与注册... 3

3.2       
协议的注册与使用... 3

3.3       
数据的存储规范与建议... 3

4      
界面的创建与管理... 4

4.1       
主界面的继承关系与显示方式... 4

4.2       
各页面的添加与跳转方式... 4

4.3       
页面内控件的使用原则... 4

 

 

 

1       前端（系统）功能的框架结构

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

 

但是该项目用的不是明显的MVC的原因是缺点明显：

      （1）增加了系统结构和实现的复杂性。对不熟悉项目的人难以使用规范。

         对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

　　（2）视图与控制器间的过于紧密的连接。且项目的视图经常变化。

          视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

　　（3）视图对模型数据的低效率访问。

            依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

这里核心的缺点在于，MVC 模式是“交互式的（interactive）”（这与反应型截然不同）。在传统的 MVC 之中，Controller将会调用 Model 上的更新方法，在成功（或出错）之时会确定如何更新 View。他指出，其实并非必须如此，这里还有另外一种有效的、反应型的处理方式，我们只需这样考虑，只应该将行为传递给 Model，不管输出是什么，也不必确定 Model 该如何进行更新。

 

所以该项目更倾向于SAM的框架:

 

 

 

首先有一个不会变的基础数据，模型基于此基础数据，加上状态构建出一个Data 类作为模型的存储数据。在模型中定义可以变化数据的行为，而试图界面只是主动的调用这些行为来改变数据，当模型接受到行为变化时，在自身做处理（或与服务器通信），最后在处理完数据后抛消息，界面接收到此消息得知数据改变完毕，重新获取数据刷新界面。

 

2       配表数据的读取

2.1   配表管理类的创建与规范

继承自 基础配表管理类 BaseCfgMgr 的单例类。

在配表管理的管理类 CfgMgrList 中注册，有两种读取方式：旧方案与新方案。由于旧方式采用一次性读取完整配表的方式，造成第一次读取时加载时间过长、数据臃肿（后期才需要得到数据在前期时用户接触不到），内存占用过多（约100M）等问题。

在新方案中做出新的需求：对配表数据的延时读取（在需要时做检查，没有数据再读取并保存）、删除数据（过场动画配表、新手关卡配表等）、修改数据等。

重写获取配表列表的函数 getDataPariList函数，该函数返回一个数组，元素仍为数组，该数组元素可以最多设置 6 个值，依次为：表名、XXX、基本结构类、主键、存储的变量（字典或数组）、对应多语言表。

重写对配表每行的读取函数

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.2   Tab配表数据的读取

2.3   Xml配表数据的读取

2.4   数据管理类的规范与建议

3       数据模型的存储与通信

3.1   模型的创建与注册

3.2   协议的注册与使用

3.3   数据的存储规范与建议

1.函数的设定不与页面需求紧密相关，而是与数据的存储方式相关

4       界面的创建与管理

4.1   主界面的继承关系与显示方式

4.2   各页面的添加与跳转方式

4.3   页面内控件的使用原则