标签：统一 开发 ... 更新 附加 ble 额外 序列化 内存地址
//1)非持久化程序.
//2)非持久化程序中的持久化.
//3)持久化程序.
//4)面向持久化开发的对比.
//5)某些持久化工具使用.
//6)小结.
//2)
//假如武器仓库非常庞大.100w条甚至更多.
//那么这个数据就必须持久化了.放在内存是不现实的.
//也不能一次从文件中读出.所以只能分批读起.
//之前仓库的public属性,必须改为private.封装起来.
//只提供,插入数据,和读起数据的方法.
//到这里突然发现.忽视了一个问题.
//持久化之后.之前存储了武器指针的地方.就是一个遗漏了.
//虽然使用智能指针.可以避免空指针的问题.
//但是要对这个数据做处理的时候.就会出现问题.
//比如,更换武器.
//之前的武器必须把used设置为false.
//但是可能此数据已经在文件中了.更改了内存的数据.但是无法反应到文件中.
//思考了一下,必须给所有需要持久化的数据,附加一个文件索引标志.
//当持久化时,把标志补充上去.这样所有的数据,都可以知道自己是否已经持久化了.
//内存中的操作,必须检测,并作出判断,是否要额外对外部数据进行更新.
//所以,内存持久化后,更新外部文件索引到内存.
//对内存的操作,检测是否已经持久化,并作出对应的操作.以保持数据一致性.但对于外部操作来说,不必知道数据是否持久.
//目前来说,持久化要解决的就是如何把原来通过指针定位数据的方法,在外部文件中实现,加个外部文件的索引给数据本身.就好了.
//一个是内存流和内存的关系(通过指针),一个是内存流和外部数据流的关系(通过2者都加一个外部数据索引)
//而外部数据和外部数据的相互关系,也是通过外部数据索引.
//所以是否,一开始就面向数据库开发.就已经解决了面向对象开发后,补充持久方案这种情况,需要的额外处理?
//比如自增列的值.就好比一个对象的内存地址.而没有自增列的表.就表示舍去对象的地址比较法,而用内存中的对象的成员数据组合来对比.
//ok.逻辑通了.开工测试.
//发现还有一个问题.持久化后的数据,如果要加载到内存中,如何让已经存在的删除.只保留一份?难道要采用链表模式,保留全局链头?
//怎么有点复杂了...难道要根据引数,来决定是否持久化.避免不统一问题.但是这个应该会影响数据的一致性.如果碰到程序中断问题.
//思索无果.
//非持久化的思路开发,要完美转到持久化.好像会死人.
//只能考虑实时的持久,才不会让开发难度扩大.最多封装一下,持久层.方便之后采用更灵活的方法..那基本就属于面向数据库开发了.没办法啊,关系型数据库这么流行.
//参考了一下最广泛使用的orm,一般有3种方式.Single-table,Joined-subclass,Table-per-concrete-class
//选择Table-per-concrete-class,第一种简单,但违背数据3范式.第二种,不错,但是可以稍微复杂了点.反正通过视图,可以也可以连接.
//每个具体类一个表,这样,生成对象时可以很简单的知道要插入数据了.表包含从基类继承的所有数据成员.、
标签：统一 开发 ... 更新 附加 ble 额外 序列化 内存地址
原文地址：http://www.cnblogs.com/lsfv/p/6250865.html
