是否通过存储库/服务/其他持久化 XML/CSV/其他答案

【问题标题】：Does One Persist XML/CSV/Other Through Repositories/Services/Other是否通过存储库/服务/其他持久化 XML/CSV/其他
【发布时间】：2010-09-29 08:14:03
【问题描述】：

我有一个从 CSV 文件或数据库中导入信息并将其导出为 XML 的应用程序。此 XML 当前正在保存到文件中。但是，由于项目需要，我决定将此 XML 保存到数据库中可能会更好。

目前我有处理导入/导出数据的 CSV、XML 和 SQL 存储库。 XML 存储库将传入的对象保存到文件中。它目前是存储对象到 XML 的映射的地方，因此它是唯一知道这种结构的地方（同样，它们各自结构的其他存储库）。

现在我想将 XML 存储在数据库中，我开始质疑这种架构。为了插入数据库，必须可以从 SQL 存储库访问 XML 的结构（注意，其他列中的数据可以与 XML 一起插入到数据库中）。这让我想知道 XML 表示是否应该存储在对象本身中，或者存储在服务层或其他地方。

解决此问题的最佳方法是什么？

更新：澄清我的问题。 XML 存储库当前保存在一个文件中。在我看来，保持 XML 结构知识的水平是错误的，因为这样我就无法灵活地将 XML 表示形式保存到我想要的任何介质上。让对象了解它的 XML 表示（或 CSV 表示等）是糟糕的设计吗？该结构的知识是否应该保留在另一个级别，那将是什么级别？

【问题讨论】：

标签： c# .net design-patterns architecture oop

【解决方案1】：

如果你希望 SQL 存储库能够使用现有的 xml 层，那么我确信某种基于接口的抽象（提供程序/IoC/DI/等）是可能的，以便 SQL 存储库可以消费xml 堆栈，而无需明确了解它。

当然，如果对象模型本身定义了 xml 结构（通过 XmlSerializer 等的属性），那么这更简单，并且 xml 存储库变得相当简单。

至于了解数据库inside的结构：看你是否需要查询数据库里面的数据。如果是这样，您可以在 SQL Server 中做很多事情——例如，您可以将 xml 列绑定到 xsd，或者您可以将部分 xml（通过 udf/xquery）提升为持久的索引列。但是，如果您只是使用数据库进行存储，那么这不是必需的 - 事实上，如果您需要在以后更改 xsd，在数据库中使用 xsd 是一个主要的 PITA（这不是微不足道的）。

【讨论】：

感谢您的回复，马克。我更新了这个问题，因为我可能不清楚我想解决什么问题。

【解决方案2】：

您还可以尝试使用原生 XML 数据库，例如 eXist，它可以满足您对 XML 存储和检索的需求。

更新：另一个解决方案可能是使用 DBMS 的 XML 功能。几乎所有现代 DBMS 都支持 XML 类型，因此最好的方法应该是这种方式（对要存储数据的列使用 XML 类型）。

更新 2：如果您只需要存储结构化信息（从 CSV 导入并将其存储在单个 XML 文件中，如果我没记错的话），为什么不使用普通旧的RDMBS？我发现将数据存储在可以不受控制地增长的 XML 文件中没有任何优势。当您想从该文件中检索一些数据（无论是否汇总）时会发生什么？它越大，完成这项工作所需的时间和计算机资源就越多。如果您使用 SAX，您将需要处理整个文件，因此访问文件末尾的数据将比访问文件开头花费更多的时间。使用 DOM 会更糟，因为文件越大，处理它所需的内存就越多。

另一方面，如果我理解错了，您需要保留许多 XML 文件，并且每个 XML 文件本身作为一条信息都是有意义的（您必须交付 XML 文件或 XML 文件的片段作为结果) 我会采用原生 XML 数据库方式，因为它是存储和访问这些数据的最自然方式。

【讨论】：

感谢费尔南多的回复。我更新了问题，因为我可能不清楚我的问题。

【解决方案3】：

您不只是将您的 XML 存储库更改为具有 SQL 后端。 yopur 存储库做什么并不重要，它们只是用于存储和检索数据的“黑匣子”。将 XML 知识保存在 XML 存储库中，并使用 SQL 对其进行后端处理。

您可以将其链接到您的 SQL 存储库或单独保存。

【讨论】：

感谢布罗迪的建议。但是，我想插入一行包含除 XML 之外的其他信息。让 XML 存储库持久保存到数据库，意味着我必须将其他信息插入 SQL 存储库，然后更新 XML 存储库中的 1 列。

【解决方案4】：

持久性可以被认为是一个横切关注点，这意味着对象不应该关心持久性是如何执行的，只关心它应该被执行；例如，您可以定义一个 PersistentStoreFactory 来创建实现 PersistentStore 接口的对象，该接口具有单个 Generic Persist 方法。

然后您可以使用 Persist 属性装饰该类，该属性将使用工厂创建 PersistentStore，然后调用传递对象实例的 Persist 方法。如果您将来决定要为不同类型的类使用不同的持久性机制，您可以扩展您的属性以具有字符串类型的参数以公开 PersistanceMedia 即数据库、文件系统、云、URL 等

【讨论】：

【解决方案5】：

如果 XML 的结构不变，您可以在 Easy Xml Serialization 上查看我的博文。它允许编写 XML，但主要是读取它。一旦为 XML 创建了所有类，您就可以通过代码轻松访问对象并直接从代码中制作/运行批处理脚本，同时确保数据有效并遵守特定架构。

当然，最好的办法还是做 CSV > 如果可能的话，直接用一些 DTO 来做数据库。

【讨论】：

【解决方案6】：

在我看来，convert-object-to-text-format 和 store-text-somewhere 的过程可以而且应该是可分离的。我猜这些东西中的哪一个是“主要的”取决于你的应用程序的结构。也就是说，无论你

告诉对象“自己去存储”，应用程序的配置决定这意味着 X 格式和 Y 存储。
告诉对象“将自己存储在数据库中”，然后数据库存储会询问对象的文本格式（或将对象传递给返回该文本的服务层）。
告诉对象“去存储你的 XML”，然后序列化过程就知道选择哪种存储机制。

当我说“配置”时，它可以像应用设置中的某些内容一样简单，也可以像应用启动时实例化特定组件的 IoC 容器一样复杂/强大。

您应该能够封装序列化和存储过程，以便改变您对它们如何连接在一起或添加新选项的想法，而不需要您重写太多应用程序。

【讨论】：

【解决方案7】：

虽然许多数据库支持直接存储 XML，但我认为尝试这样做会很痛苦（根据经验）。如果架构发生变化，那么您需要将每条记录更新为新架构。

我建议，如果您要将其存储在数据库中，则将数据存储在更易于修改和管理的表中。

此外，您应该质疑为什么要将数据存储在数据库中。如果您不打算查询数据，那么存储在平面文件中也一样好。

我并不是说你的做法是错误的，而是仔细考虑你的要求。

【讨论】：