我正在经历Best Practices: Data Contract Versioning时,对于相同的数据合同实际上意味着什么以及我们如何才能真正创建新的数据合同感到困惑。
我经历过Data Contract Equivalence,并且不确定两者的含义是否相同。
按照规范的以下方框:
尽管在这些示例中,名称已更改(通过添加“ 2”),但 建议通过附加名称来更改名称空间而不是名称 具有版本号或日期的新名称空间。例如, 'http://schemas.contoso.com/2005/05/21/PurchaseOrder'数据合同 会变成 'http://schemas.contoso.com/2005/10/14/PurchaseOrder'数据合同。
这是否意味着更改数据协定的“名称”或“名称空间”使其成为新的数据协定,并且如果两个数据协定的“名称”和“名称空间”属性具有相似的值,则它们是相同的吗?
我在这里出问题了吗?
相同数据合同和等效数据合同之间也有区别吗?
答案 0 :(得分:2)
简短的回答:是:每个定义使用两个具有不同名称空间的协定,即使它们定义的操作相同,也可以使用两个不同的协定,而具有相同名称和名称空间的两个协定将被视为相同的协定
。这里的重点是,您可以拥有两个仍然相互兼容或部分兼容的合同(具有两个不同的命名空间),如果客户端接受的话。
作为一个(有点干的和理论上的)示例,假设您有一个定义两个操作的协定:Do-X
和Do-Y
。现在说您决定删除Do-Y
,并用新的操作Do-Z
替换它。
然后,最佳实践是为合同保留相同的名称,但更改名称空间以反映功能的更改。这将如何影响任何客户可能取决于几个因素:
如果客户端未验证架构,并且不使用Do-Y
(而仅使用Do-X
),则即使该服务该客户端仍应能够与该服务进行通信使用新合同,而客户仍在使用旧合同。
如果客户端确实需要架构验证,则他将需要使用与托管服务相同的架构(名称空间),否则验证将失败。
如果客户端使用Do-Y
,但未验证架构,则在尝试执行操作Do-Y
之前,您可能看不到任何错误,这时显然会失败。
为避免发生上一个示例中的错误,典型的最佳实践是添加但不删除操作;如果在上述示例中,您在新版本中添加了Do-Z
,但没有删除Do-Y
,那么使用旧合同的非验证客户端仍然可以使用。
但是,如果使用严格的验证,则在添加Do-Z
之后,旧客户端将无法使用新的服务合同。实际上,即使操作完全相同,也无法使用新合同。在这里,您可能会说旧合同和新合同是 等价 (它们定义了完全相同的操作),但仍然 不相同< / em> ,因为它们位于不同的命名空间下。