我目前正在编写一个 IRC 客户端，并且一直在尝试找出一种存储服务器设置的好方法。基本上是大多数 IRC 客户端所拥有的网络及其服务器的大列表。
我决定使用 SQLite，但后来我想以 XML 格式（也许是权威的）在线免费提供该列表，以供其他 IRC 应用程序使用。所以现在我可以将设置以相同的格式存储在本地。
我对 ADO.NET 或 XML 的经验都很少，所以我不确定在这种情况下它们会如何比较。
以编程方式更容易使用吗？一个更快吗？有关系吗？
【问题讨论】：
标签： c# .net xml sqlite ado.net
我个人会使用 XML 进行设置 - .NET 已经为此而构建，因此具有许多用于将设置存储在 XML 配置文件中的内置工具。
如果您想使用自定义架构（XML 或 DB）来存储设置，那么我会说 XML 或 SQLite 都可以正常工作，因为您应该在数据存储周围使用体面的 API。
【讨论】：
每个工具都有自己的权利
我知道，围绕 XML 有很多炒作。但是您应该看到，XML 基本上是一种交换格式——而不是一种存储格式（除非您使用为您提供更多选择的原生 XML 数据库——但也可能会增加一些麻烦）。
当您的配置相当小（比如少于 10.000 条记录）时，您可以使用 XML 并且没问题。您会将整个内容加载到您的内存中并访问那里的条目。完成。
但是当您的配置如此之大，以至于您不想完全加载它时，您需要重新考虑您的决定并继续使用 SQLite，它为您提供了动态加载所需配置部分的选项。
您还可以提供一个小工具来从 DB 内容创建 XML 文件——从 DB 创建 XML 是一项相当简单的任务。
【讨论】：
这是一个比您意识到的更模糊的问题。 “设置”可以包含很多东西。
有一个很好的 .NET 基础结构用于处理配置文件中的应用程序设置。这些通常作为全局 Settings 对象的属性公开给您的程序； System.Configuration 命名空间中的类负责读取和持久化它们，Visual Studio 中内置了一些工具来自动生成处理它们的代码。此基础架构支持的数据类型之一是 StringCollection，因此您可以使用它来存储服务器列表。
但是对于大量服务器，这不是我的首选，原因有几个。我希望您列表中的元素实际上是元组（例如主机名、端口、描述），而不是简单的字符串，在这种情况下，您最终将不得不格式化和解析数据以将其放入 StringCollection ，这通常表明您应该做其他事情。此外，应用程序设置是只读的（至少在 Vista 下），虽然您可以设置用户范围以使其具有持久性，但这会引导您走上一条您在提交之前可能想要了解的路径。
所以，我要考虑的另一件事是：您的服务器列表只是一个列表，还是您有一个内部对象模型来表示它？在后一种情况下，我可能会考虑使用 XML 序列化来存储和检索对象。 （我会在应用程序配置文件中保留的唯一内容是序列化对象文件的路径。）我这样做是因为将简单对象序列化和反序列化为 XML 非常容易。您不必担心设计和测试正确的序列化格式，因为这些工具会为您完成。
我考虑使用数据库的主要原因是我的程序是否执行了一堆操作，其结果需要是原子的和持久的，或者出于某种原因我不希望我的所有数据一次都在内存中。如果每次 X 发生时，我都想要它的永久记录，这将引导我走向使用数据库的方向。通常，您不想将 XML 序列化用于类似的事情，因为如果您将所有对象保存到单个物理文件中，您实际上无法仅序列化一个对象。 （虽然简单地序列化整个对象模型以保存一个更改当然不是疯了。事实上，这正是我公司的产品所做的，它指出了另一种我不会使用数据库的情况：如果数据的模式是经常更换。）
【讨论】：
看起来您在这里有两个独立的应用程序：一个 Web 服务器和一个桌面客户端（因为传统上这些应用程序运行在此），每个应用程序都有自己的存储需求。
在服务器端：使用关系数据存储，而不是 Xml。基本上在某些时候，您需要将用户数据与服务器上的其他用户数据分开。 XML 不是一个很好的存储。
在客户端：这并不重要。 XML 可能会更容易操作。不要认为因为你在一种环境中使用一种技术，你就必须在另一种环境中使用它。
【讨论】：