容错性读取器

Posted 2020-10-31 chenxygx

TolerantReader

使用Web服务的好处之一是它可以帮助您分离系统的各个部分。人们可以在不同的代码基础上进行一定程度的分离。尽管你得到了一些解耦，但你不能完全消除耦合，因为服务仍然需要通过它们的接口相互通信。可悲的是，许多团队使这种耦合比应该更糟糕。

解耦合作的治理法律应该是Postel定律：

在你所做的事情上要保守，在你接受别人的事情时要自由。

- 乔恩Postel

在合作服务的情况下，最棘手的问题之一就是进化。虽然有些人认为你应该第一次正确地定义你的服务定义，所以你永远不需要改变他们，但是我的经常读者不会惊讶地发现我离开他们的派对。为了能够发展服务，您需要确保提供商可以进行更改以支持新需求，同时最大限度地减少对其现有客户的破坏。

自从撰写这份bliki条目以来，Rob Daigneau在服务设计模式中发布了这种模式的完整描述

填补这个问题的常见方法是使用某种模式驱动的服务端点绑定。一个例子是从XSD定义中生成代码的C＃类。这被视为一种节省时间的功能 - 服务提供商发布其服务的XSD定义，消费者获取副本并生成一个类。看，可以不编程。它运行良好，直到提供者需要对接口进行任何更改，例如添加字段。将字段添加到像这样的界面不应该是任何人的重大改变 - 但通常会打破这些方案。

我的建议是在从服务中读取数据时尽可能宽容。如果你使用的是XML文件，那么只需要你需要的元素，忽略任何你不需要的元素。此外，对您正在使用的XML的结构做出最小假设。而不是像/order-history/order-list/order使用一样使用 XPath搜索 //order。你的目标应该是允许提供者做出任何不应该破坏你的代码的改变。一组XPath查询是为XML负载执行此操作的极好方式，但您也可以使用相同的原则来处理其他内容。

最重要的是，确保只有一点代码能够读取像这样的数据有效载荷。数据传输对象的目的之一是将数据有效载荷包装在方便对象的后面，这样系统的其余部分就可以走到anOrderHistory.orders 并且不受变化的影响，甚至会破坏容错读者。

即使您的数据传输协议是二进制文件，也应该牢记这一原则。假设您在连接的两端都有java程序，并且想要使用二进制传输来保持消息的大小。在这种情况下，大多数人会使用java的内置序列化机制来直接序列化对象，但如果一方添加了一个字段，则传输会中断。首先将数据放入通用集合（列表和地图），然后序列化这些集合，可以很容易地避免这种情况。如果您为地图添加额外的字段，它仍然会在另一端反序列化，容错读者很容易忽略它。

为了帮助服务提供商发展他们的服务，您可以传达您正在阅读的通信的哪些部分。这样做的好方法是给读者和测试者发送它们，以便他们可以在构建过程中使用它们来检测潜在的破坏。有些人可能会认为这是消费者驱动合同的下一步

进一步阅读

服务设计模式中有这种模式的完整描述。

几年前，我的同事Ian Cartwright发布了一系列有用的博客文章。他指出，模式验证提供了一种错误的安全感，并且在序列化中存在一些危险，无论是通用还是特定的域对象。

Saleem Siddiqui描述了一个宽容的读者如何与一个善良的作家合作。