软件工程师的标识并存储持久性数据

作者:Gman更新于： 2018-03-23 15:34:49

　　ARENA系统处理两个需要被存储的对象集合。第一个集合包含由游戏组织子系统标识持久性对象建和访问的对象(例如,系列赛Tournament、游游戏Game、比赛Match、选手Player),这些对象需是持久对象,以便追踪联盟Leagues、比赛Matches、系列赛Tournaments和选手Players的过程,第二个集合包含在比赛Matches中由端到端竞赛dampeer和比赛前端到端Matchfrontendpeer创建和访问的对象,这些对象用来为观众Spectators重播比赛、修复由系统崩溃所中断的比赛Matches。第一个集合中的对象被很好定义,而且在整个ARENA系统的生命周期中发生变化的可能性很小。

　　第二个集合中的对象对每个游戏Game米说是特定的,并由游戏Game的开发者做出了定义。因此,我们决定用ARENA系统中的克技场存储子系统Arenastorage来管理第一个集合中的持久性对象,而让游戏开发者决定定如管理在特定游戏构件中比赛Matches的状态。每个游戏Game的持久性对象将只能通过个由各个游戏Game自身所实现的通用游戏Game接口来访问。

　　我们可以选择一种存储策略在系统设计中选择一个持久性存储策略,允许我们处理其他与存储管理相关的问题例如并发控制和故障恢复。例如,许多数据库管理系统允许并发查询并且提供事务机制来确保数据的一致性在ARENA系统中,我们的最高优先级设计目标是最小化操作成本,所以我们首先秀虑采用平台文件来进行存储。由于没有数据库管理系统需要进行配置和管理,这样一个系统是很容易被安装上的。

　　然而,一个仅基于平台文件的系统将不能适应带有多个游戏和成千上万游戏者这样的大规模安装。为了满足所有的这些目标,我们选择一个复合策略。存储子系统将提供一个抽象接口,它既可以使用平台文件又可以使用关系数据库实现。当首次安装一个竞技场Arena的时候竟技场操作者Arenaoperator选择哪种实现更适合设计目标。竞技场操作者Arenaopera将不能在系统运行时改变策略,但是可以将持久性对象从平台文件转换成数据库,并且在系统重新配置期间备份。

　　这将增加ARENA系统的开发成本,但是为竟技场操作者Arenaoperator进行选择提供了更大的弹性。为了降低开发风险,ARENA系统的初始原型将只采用平台文件。第二个原型将采用独立于于数据库的应用程序员接口(API)(例如,JDBCUDBC,2009),以便在一个关系数据库中存储持久性对象,从而使竞技场操作者Arenaoperators可以使用不同的相关产品。

　　小编结语：其实对于很多的游戏开发者将个别地选择游戏的存储问题来说。当给定本质上是顺序的游戏数据据时,我们就可以预测出游戏将采用平台文件来进行存储。