场景
在应用层面上需要新增员工,删除员工,修改员工以及查询操作。
而负责给应用层提供接口的Core层将这些员工信息保存到文件里面。
思路
回顾下映射IO和内存池的应用
映射IO可以把一个文件映射到内存上,通过操作这段内存来达到修改文件的效果。
而内存池(在这里只说固定内存池),就是一开始先分配一块内存,当别人需要的时候就拿出一小块内存给别人用。
首先Core层初始化的时候要得到文件路径和结构体大小,然后用映射IO得到一块内存,然后再把这段内存作为内存池来使用。
员工信息可以当作一个结构体,应用层需要新增员工的时候,Core层就分配这个结构体大小的内存来给应用层,从而达到将该员工写入文件的效果。删除也是类似。
还需要思考的问题
1.Core层加载文件时要知道哪些块是已经在用,哪些块还没被使用,以及存储的结构体大小。
因此文件除了需要存应用层存放的数据还需要额外的空间记录别的信息。如图。
2.当DATA块已经存满了,需要扩充文件大小来存放新数据。新扩充的那块同样需要额外的空间存放信息。
考虑到存放的结构体都是固定大小的,因此UNIT_SIZE只需存放一次就好了。同样,每次文件扩充的大小也是固定的,每一块能够存放的单元个数也是固定的,COUNT只存一次就好了。
但是,即使这样,DATA块和DATA块之间隔着一个STATUS块,这样子可能出现内存不对齐的问题。这个问题在当前这种设计下是不可避免的。
设计
我最终的设计并没有去解决内存不对齐的问题,而是避开了该问题。如图。
首先UNIT_SIZE和COUNT不是放在额外的空间,而是放在第一个DATA块的第一个UNIT,而记录DATA块中每个UNIT的使用状态的STATUS块也不保存到文件,而是在Core层初始化的时候传入应用层的写的方法来判断每一个UNIT的状态。
其他
代码在公司电脑上面,所以就先不贴代码了。
写的不好的地方可以评论指点下。