在简单的.NET Windows应用程序中将数据保存在何处？

话虽这么说,我绝不会梦想使用任何类型的数据库来存储简单的客户端数据.复杂性和开销似乎是不合理的,特别是当SQL数据库的优点几乎在应用程序类型上丢失时.如果您的数据集可以完全加载到RAM中,或者从保存的文件中按需加载数据的性能影响可以忽略不计,那么您可以很好地探索替代选项.我考虑存储到客户端数据库的唯一情况是,如果通过更智能/更高效的代码设计无法实现更快的数据检索时间,或者应用程序是否可以从索引和搜索功能中获益像MySQL可以提供的.

相反,我发现我自然倾向于在树中构建数据.对于速度不是最重要的应用程序或者我没有处理特别复杂的数据类型的任何应用程序,我选择XML serialization.不仅是查询和修改XML文件比使用数据相当小的数据库快得多set,标准的Microsoft DOM库使得处理XML数据源变得非常简单.序列化类的实例是内置在.NET Framework中的,并且让我希望在数年前我花费所有时间编写数据存储和检索代码时,我已经拥有了这个功能. XML的其他优点是,即使添加了功能,它也可以在未来版本的应用程序中消除版本问题,并且必要时可以手动查看/编辑数据文件.可移植性也很好,允许其他程序轻松读取和导入您的数据,如果发生这种情况,您不会冒着使用多个同时读/写来破坏数据库的风险.最后,为了它的价值,我发现将自定义数据集序列化为XML文件在调试中非常有用：我可以保存状态,然后打开XML文件以确切地查看存储的数据.

在XML不太符合要求的应用程序中(通常是因为我试图欺骗并保留加载到内存中的数据管理类的状态),我选择了binary serialization.如果你’,这也是XML的一个很好的替代品.寻找更快的访问时间和数据/数据结构的复杂性并不像XML的分层格式那样自然.这也构建在.NET Framework中,甚至可能比XML序列化更简单(如果可能的话).这种类型的数据存储的两个主要缺点是无缝版本变得几乎不可能,并且您的数据以用户或其他应用程序无法访问的专有格式存储.如果版本控制不是您的应用程序的问题,那么可能没有太多担心.但是,有了我编写过的几个数据管理应用程序,我在以后回过头来添加功能时没有采取预防措施来读取先前版本中创建的数据文件.

无论哪种方式,使用二进制或XML序列化,我都喜欢作为开发人员为我提供的灵活性,它有多个独立的文档文件.我可以将某些文件扩展名与我在shell中的应用程序相关联,用户体验对于备份这样的事情变得非常直观,用户可以轻松地与我的应用程序中的其他人交换我的应用程序中创建的文件.您如何看待Microsoft Word变得如此受欢迎？