C# 关于使用XML作为存储过程参数和返回类型的意见

这对我来说是新的。我有一个新老板在工作，他坚持我们从现在开始做的每个查询都是一个包含XML序列化参数和返回类型的存储过程

---

我还没有运行过任何测试，但这让我觉得有些过火，在很多方面可能是性能杀手。您的体验如何？

虽然它是一个明显的性能杀手（想象一下解析存储过程返回的几兆XML），但它更是一个生产力、可扩展性和可维护性杀手。在T-SQL中使用XML并不是完全无痛的，也不是无缝的。支持将是一场噩梦：想象一下向resultset添加一列，这将导致序列化和反序列化代码中的大量修改

另外，您既不能使用ORM工具，也不能使用简单的结果集映射器（iBATIS或BLToolkit）。

它可能允许您实现某种程度的向后和向前兼容性（因为程序可以开始理解额外的参数）-但我要说，全面应用它几乎在所有方面都是荒谬的

我建议你让你的老板给出他认为这是个好主意的技术原因。

使用单个参数是一种非常简单的方法，这可能会使引用存储过程调用的代码看起来更整洁、更简单

坚持对于新老板来说，在代码审查和标准化方面是一个非常坚定的立场。在团队中，常见的编码实践是件好事，但我感到，通过在各个地方传递XML，可以隐藏一些非常糟糕的小错误。是的，这可能会使响应看起来更一般，但如果您正计划将XML传递给另一个进程，将其包装在一个层中不是更好吗：您可以将数据访问层紧密绑定到存储过程，然后从那里显式地构建XML，获得类型检查、TDD和辅助功能

---

听起来好像有人刚刚读到你可以做并且思考“XML很好，对吗？”不用花太多时间考虑是否应该这样做

不久前，我也遇到过同样的情况，除了性能开销之外，这种方法还存在一些非常严重的错误。在Xml文档中添加/删除/重命名标记非常容易，除非存储过程保持最新，否则在数据库中会发现异常数据。我的建议是避免这种做法-只是不要这样做

---

顺便说一句，你是AO的老板吗？

嘿，让我们来看看我们最不可扩展的组件，让它做密集的CPU工作-p

好吧，那是开玩笑。Xml作为参数和返回值在一些特定情况下用于结构化数据，但一般来说，平面TDS流（即网格）要高效得多。对于输入，CSV（通过udf拆分）或表值参数（SQL 2008）都是不错的选择

2005+中的Sql/xml比openxml好得多——事实上，一旦xml在服务器中存储和索引（使用

xml

数据类型），它就相当高效了——但作为输入和输出，如果不小心，它可能成为瓶颈

---

不要将其设为默认值，但将其视为可用选项之一。

< P>有趣。在SQL中解析字符串绝非易事。xml将实现什么？（当然不是松散耦合，因为数据库和应用层的解耦已经通过存储过程实现了）

---

我相信您编写了两个执行相同操作的存储过程，但一个以普通方式编写，另一个以xml编写。希望你的老板能“看到”并接受这个显而易见的决定。

我以前说过，我要再说一遍：没有灵丹妙药

使用XML作为存储过程的输入和输出是一个银弹解决方案，它只证明了一件事：在一个实例中可能是一个好选择的一个解决方案在许多（可能是绝大多数）其他实例中是非常不合适的

如果愿意，请考虑一个不带参数并返回单个标量值的存储过程。在这种情况下，XML显然是过火了

还可以考虑一个存储过程，在该存储过程中，传递一个日期范围（两个单一的日期值），并从一组属于该范围的联接表中返回所有行。用XML封装日期可能并不过分，但封装您将返回的可变数据量可能会过分。你可以得到零行。你可以拿回成千上万的

考虑从存储过程返回的数据类型取决于传递给它的参数的类型和值的情况。此外，由于行集的性质相当不稳定，这些行集中的一个或多个可能会随之更改，需要更改编码。最后，您有了一个可能适合XML的解决方案

那么，您是否应该惩罚整个代码库，因为其中的一小部分存在易变性问题？或者，您是否应该设计一个解决方案，将这些易失性数据集封装在一个适当设计的外观后面，以保护系统的其余部分不受这种易失性的影响

---

您将发现，XML无处不在的银弹不是银弹，而是核弹头。当你想要一个可以打击单一目标并解决你的问题的解决方案时，你最终会得到一个可以摧毁眼前一切的解决方案，因为你将在这个问题上带来远远超过你合理处理能力的火力。然后，与通常情况一样，武器摧毁了试图使用它的人。

需要在客户端（浏览器）和服务器执行的网站程序之间传输数据字符串消息。但是，这些消息字符串应该具有简单的结构规则，以便能够将其信息快速解析为命名参数和参数字段组件。XML是作为智能语言创建的