目录
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.函数的设定不与页面需求紧密相关,而是与数据的存储方式相关