这对我来说是新的。我有一个新的老板，他坚持认为我们从现在开始的每一个查询都是带有XML序列化参数和返回类型的sproc。
我还没有进行过任何测试，但这让我感觉有点过分，可能在很多方面都是性能杀手。你有什么经历？
答案 0 :(得分：4)
虽然是一个明显的性能杀手（想象一下解析了几个从sproc返回的XML），但它更具有生产力，可扩展性和可维护性杀手。在T-SQL中使用XML并不是无缝无缝的。支持将是一场噩梦：想象一下，在结果集中添加一个列，这将导致序列化和反序列化代码中的大量修改。
另外，您既不能使用ORM工具，也不能使用简单的结果集映射器（iBATIS或BLToolkit）。
答案 1 :(得分：3)
它可能允许你一定程度的向后和向前兼容性（因为proc可以开始理解额外的参数） - 但是我会说全面应用它是荒谬的所有方式。
我建议你让你的老板说出他认为这是个好主意的技术原因。
答案 2 :(得分：3)
嘿，让我们采用我们最不可扩展的组件，让它做密集的CPU工作;-p
好的，那是脸颊上的舌头。 Xml作为参数和返回值在少数具有结构化数据的特定情况下使用，但通常平坦的TDS流（即网格）效率更高。对于输入，CSV（通过udf拆分）或表值参数（SQL 2008）都是不错的选择。 2005+中的Sql / xml比使用openxml好得多 - 事实上，一旦xml在服务器中存储和索引（使用xml数据类型），它就非常有效 - 但作为输入和输出它如果你不小心，可能会成为瓶颈。
请勿将其设为默认选项，但请将其视为可用选项之一。
答案 3 :(得分：2)
我在一段时间内处于同样的情况，并且除了性能开销之外，我们还有一些非常讨厌的错误。在Xml文档中添加/删除/重命名标签非常容易，除非您的SProc保持最新状态，否则您将在数据库中找到异常数据。我的建议是避免这种方法 - 只是不要这样做......
是的，你的老板来自AO吗？答案 4 :(得分：1)
使用单个参数非常容易（读取：混乱）方式，这可能使引用存储过程调用的代码看起来更整洁，更简单。
坚持是新老板采取代码审查和标准化的强烈立场。常见的编码实践在团队中是很好的事情，但是让我觉得你可以通过在这个地方传递XML来隐藏一些非常糟糕的小事。是的，它可能会使响应看起来更一般，但如果您计划将XML交给另一个进程，将其包装在一个层中，那么它可能会更好：您可以将数据访问层紧密绑定到存储过程然后从那里显式地构建XML，获得类型检查，TDD和辅助的好东西。
听起来有人刚刚读到你 可以 这样做并认为“XML很好，对吧？”没有考虑你 是否应该这样做。
答案 5 :(得分：1)
有趣。在SQL中解析字符串并非易事。 。 xml会实现什么？ （当然不是松散耦合，因为已经通过存储过程来实现数据库和应用程序层的分离）
我相信你写了两个存储过程，这些过程做了相同的事情，但是一个用普通的方式编写，一个用xml编写。希望你的老板可以“看到”并接听明显的电话。
答案 6 :(得分：1)
我以前说过这个，我会再说一遍：没有银弹。
使用XML作为存储过程的输入和输出是一个灵丹妙药的解决方案，它只证明了一件事：在一个实例中可能是一个好选择的一个解决方案在很多方面是非常不合适的（可能绝大多数其他人。
如果愿意，请考虑一个不带参数并返回单个标量值的存储过程。在这种情况下，XML显然有点过分。
还要考虑一个存储过程，在该过程中传递日期范围（两个单个日期值）并返回属于该范围的一组连接表中的所有行。在XML中封装日期可能不会过度，但是封装可能会返回的可变数据量。你可以回到零行。你可以找回成千上万的。
考虑从存储过程中获取的数据类型取决于传递给它的参数的类型和值的情况。此外，因为行集的性质相当不稳定，所以这些行集中的一个或多个可能在路上改变，需要编码改变。最后，您有一个可能适合XML的解决方案。
那么，您是否应该惩罚整个代码库，因为它们中的一小部分存在可变性问题？或者，您是否应该设计一个解决方案，将那些易变数据集封装在正确设计的外观背后，以保护系统的其他部分免受这种波动的影响？
你基本上会发现XML Everywhere的银弹不是银弹，而是核弹头。当你想要一个可以攻击单个目标并解决问题的解决方案时，你最终会得到的东西会摧毁所有可见的东西，因为你会比你可以合理处理的问题带来更多的火力来解决问题。然后，通常就是这种情况，武器摧毁了那些企图挥舞它的人。
答案 7 :(得分：1)
需要在客户端（浏览器）和服务器执行的网站程序之间传输数据串消息。但是，这些消息字符串应该具有简单的结构规则，以便将其信息快速解析为命名参数和参数字段组件。 XML被创建为一种智力练习，以某种方式描述充满HTML对象的页面的复杂对象关系和属性。 XML对于教授理论家来说是非常迂腐的深奥的练习，但作为大多数网站交流的实用工具，这是一个笑话。