我做了很多系统编程，其中我的应用程序没有机会被用来通过Web进行通信或者通过浏览器查看。但是，管理部门已在推动使用XML。例如，如果我想保留时间日志，则可以使用如下文本文件：

命令日期时间项目
在2008/09/23 08:00:00 PROJ1
更改2008/09/23 09:00:00 PROJ2
out 2008/09/23 12:00:00 PROJ2
在2008/09/23 01:00:00 PROJ3
出2008/09/23 05:00:00 PROJ3

XML看起来像这样：

<时间日志>
<timecommand cmd = in date = 2008/09/23 time = 8：00：00 proj = PROJ1 />
...
<timecommand cmd =退出日期= 2008/09/23时间= 5：00：00 proj = PROJ3 />
</ timelog>

我看到的文本版本的一些初始优点是，它易于使用正则表达式读取和解析。在这种情况下使用XML有什么优势？

解决方案

我想到了几个好处：

• 解析成其他应用程序更容易
• 一目了然地了解文档的内容
• 使将数据拉入管理仪表板更加容易
• 让管理轻松愉快

缺点，如我所见：

• 意味着可能不必要地更改现有代码
• 可能会略微降低性能，具体取决于我们构建文档的方式与构建当前文档的方式
• 出于XML的考虑，这是XML，这是愚蠢的

最后，引述讽刺意味的是：XML就像暴力。如果它不能解决问题，则说明我们没有充分利用它

使用正则表达式，xml和xsl可以轻松解析它。

实话实说，除非我们将数据发送到另一个系统，否则使用XML并不是真正的"优势"。

在这种情况下，XML的主要特征是可以对XML进行验证和控制。在文本版本中，我们将如何以编程方式验证文件格式正确？ XML旨在创建结构化的有效文档，其最终收益是严格控制格式并可靠地构造了一种格式。与维护一系列用于读取文本文件的正则表达式相比，维护从XML节点读取的代码也将更加容易，而且布局合理。

XML是一种元格式，这意味着它可以更轻松地为数据定义格式。这样，多个程序(包括不同公司的程序)就可以更轻松地以相同格式读取和写入数据。它特别适合作为对复杂的分层数据的描述。

在上面概述的示例中，数据看起来是固定格式的隔离记录，没有结构或者层次结构，在这种情况下，我看不到使用XML的优势。但是，该示例可能不具有代表性，其他文件可能包含更多的结构化数据。

如果我们使用XML，则在某些方面，数据将更加"可移植"。实际上，我们在大多数环境中都可以使用数据解析器，因此编写用于分析数据的工具可能会更容易。另外，如果它是XML格式，则可以编写XSLT将其转换为其他各种格式，从而使其更易于阅读。

就是说，如果我们转而使用XML，即使是像我们给出的示例那样的简单格式，日志文件也将变得更大。

除了XML，我们可以使用其他一些选项。 Jeff的Angle Bracket Tax博客文章对此进行了一些讨论。

确实，我们应该做的是找出如何使用这些日志，然后确定哪种格式会使这些用法最容易实现。

那是一个正在进行的日志文件吗？

我们将如何编写来创建有效的文档？还是要读入，添加新条目并每次写出？

日志文件是结构简单的纯文本行的理想选择，只需将其添加到该行即可。

在大多数情况下(并非总是如此)，XML使人们更容易理解数据，因为突然之间，我们资产周围的元数据就描述了我们面前的内容(人类可读)。

XML也很容易访问。我的意思是，自从我们提到它以来，我们就不想在XML上使用正则表达式。有诸如XPATH(XML路径语言)之类的工具可以使查询XML变得有趣。当我们可以使用XPATH之类的XML轻松遍历XML时，无需编写任何其他人都无法阅读的内容。

在某些情况下，XML做相反的事情(在可读性方面)，有时XML也是开销。当我们在系统之间交换数据时，它并非总是最佳选择(例如，看看像JSON这样的轻量级内容)。而且这种交流也不需要在网络上。

虽然将XML用于数据文件意味着数据可以自我描述并且可以更好地组织，但最终结果通常是数据文件比以前大得多。

问问自己，这些文件的用途是什么？是否要更改？如果是这样，谁来付款，谁来为此预算？

在某些情况下，我喜欢XML，而在另一些情况下，我讨厌它！

在我们正在谈论的系统批处理编程的情况下，xml的主要功能是几乎所有地方都支持它。因此，我们今天编写了一个程序来使用xml处理某些数据，并且在10年内需要大修该程序并希望使用完全不同的平台时，仍然会很好地支持xml数据。

如果我们是在.NET(尤其是具有LINQ to XML的.NET 3.5)中进行开发，则与仅使用纯文本文件相比，编写用于读写XML的代码将更少。另外，XML使得任何人都能更轻松地读取文件并确切知道文件的内容和用途。而且，不必担心XML会占用更多的磁盘空间，磁盘空间很便宜。

使用基于文本的数据格式绝对没有错。数十年来，它一直是事实上的标准。大型大型大型财务系统至今仍在使用它。这样做的好处是，它的生产量很小，消耗量很小，而且重量极轻。日志文件又如何呢？我们是否知道任何生产平台都不会以定界文本格式生成其日志文件(Web，应用程序，数据库服务器)？

平面文本文件的缺点是，如果格式更改，则必须不费吹灰之力地修改生产者和使用者端，以支持格式更改。当然，如果只是一个人在消耗结果，那么我们只需要更改生产者即可。

XML的优点在于，数据的解析不仅独立于数据，而且独立于数据的格式。从逻辑上讲，我们将数据和数据格式都传递给它，然后保存！一切正常。并不是那么简单，但这是前提。我们可以更改数据的格式，而生产者和消费者只需更改即可(如果有的话)。

XML的丑陋之处在于它可能会成为一个性能巨大的狗(SOAP有人吗？)并且重量很重。我们肯定为它的可扩展性付出了代价。在某些情况下，它绝对是给定问题领域的最佳技术解决方案，而在其他情况下，则不是。

因此，如果这是人类可以阅读的简单日志，请将其保留为平面文件。如果它是一个与另一个应用程序进行通信的简单应用程序，并且通信不会随时间变化很大，那么平面文件无疑会更快，更轻松地实现，但是XML并不是一个不错的选择。如果多个应用程序需要使用我们提供的数据，或者通信更改量很大，请使用XML。如果这样做的话，随着时间的推移，接口的维护将变得更加容易。