'same data contracts' 实际上意味着什么？
What does actually 'same data contracts' imply?
我正在浏览 Best Practices: Data Contract Versioning 并且对相同数据合同的实际含义以及我们如何实际创建新数据合同感到困惑。
我已经看完了 Data Contract Equivalence，但不确定两者的意思是否相同。
根据规范中的以下块：
Although in these examples names are changed (by appending a "2"), the
recommendation is to change namespaces instead of names by appending
new namespaces with a version number or a date. For example, the
'http: //schemas.contoso.com/2005/05/21/PurchaseOrder' data contract
would change to the
'http: //schemas.contoso.com/2005/10/14/PurchaseOrder' data contract.
这是否意味着更改数据合同的 'Name' 或 'Namespace' 使其成为新的数据合同，并且如果两个数据合同具有相似的 [=26] 值，则它们是相同的=] 和 'Namespace' 属性？
我是不是搞错了什么？
同样的数据合同和等价的数据合同有什么区别吗？
简短回答：是的：每个定义都有两个具有不同命名空间的合约，两个不同的合约，即使它们定义的操作相同，而两个具有相同名称和命名空间的合约将被假定为是同一份合同。
这里的重点是您可以拥有两个仍然兼容或部分兼容的合同（具有两个不同的命名空间），如果客户接受 .
作为一个（有点枯燥和理论上的）示例，假设您有一个定义两个操作的合约：Do-X 和 Do-Y。现在假设您决定删除 Do-Y 并将其替换为新操作 Do-Z。
那么最好的做法是为合同保留相同的名称，但更改名称空间以反映功能的变化。这将如何影响任何客户可能取决于几个因素：
如果客户端不验证架构，并且不使用 Do-Y（但仅使用 Do-X），则该客户端仍应能够与服务通信即使服务使用新合同，而客户仍在使用旧合同。
如果客户端确实需要模式验证，他将需要使用与托管服务相同的模式（名称空间），否则验证将失败。
如果客户端使用 Do-Y，但未验证模式，您可能在尝试执行操作 Do-Y 之前看不到任何错误，此时它显然会失败。
为避免出现上一个示例中的错误，典型的最佳做法是 添加但不删除操作 如果可能的话；如果在上面的示例中，您在新版本中添加了 Do-Z，但没有删除 Do-Y，那么使用旧合约的非验证客户端仍然可以工作。
但是，如果使用严格验证，添加 Do-Z 后，旧客户端将无法使用新服务合同。事实上，即使操作完全相同，它也不适用于新合约；在这里，你可能会说旧合约和新合约 等价 （它们定义了完全相同的操作），但仍然 不一样，因为它们位于不同的名称空间下。
我正在浏览 Best Practices: Data Contract Versioning 并且对相同数据合同的实际含义以及我们如何实际创建新数据合同感到困惑。
我已经看完了 Data Contract Equivalence，但不确定两者的意思是否相同。
根据规范中的以下块：
Although in these examples names are changed (by appending a "2"), the recommendation is to change namespaces instead of names by appending new namespaces with a version number or a date. For example, the 'http: //schemas.contoso.com/2005/05/21/PurchaseOrder' data contract would change to the 'http: //schemas.contoso.com/2005/10/14/PurchaseOrder' data contract.
这是否意味着更改数据合同的 'Name' 或 'Namespace' 使其成为新的数据合同，并且如果两个数据合同具有相似的 [=26] 值，则它们是相同的=] 和 'Namespace' 属性？
我是不是搞错了什么？
同样的数据合同和等价的数据合同有什么区别吗？
简短回答：是的：每个定义都有两个具有不同命名空间的合约，两个不同的合约，即使它们定义的操作相同，而两个具有相同名称和命名空间的合约将被假定为是同一份合同。
这里的重点是您可以拥有两个仍然兼容或部分兼容的合同（具有两个不同的命名空间），如果客户接受 .
作为一个（有点枯燥和理论上的）示例，假设您有一个定义两个操作的合约：Do-X 和 Do-Y。现在假设您决定删除 Do-Y 并将其替换为新操作 Do-Z。
那么最好的做法是为合同保留相同的名称，但更改名称空间以反映功能的变化。这将如何影响任何客户可能取决于几个因素：
如果客户端不验证架构，并且不使用
Do-Y（但仅使用Do-X），则该客户端仍应能够与服务通信即使服务使用新合同，而客户仍在使用旧合同。如果客户端确实需要模式验证，他将需要使用与托管服务相同的模式（名称空间），否则验证将失败。
如果客户端使用
Do-Y，但未验证模式，您可能在尝试执行操作Do-Y之前看不到任何错误，此时它显然会失败。
为避免出现上一个示例中的错误，典型的最佳做法是 添加但不删除操作 如果可能的话；如果在上面的示例中，您在新版本中添加了 Do-Z，但没有删除 Do-Y，那么使用旧合约的非验证客户端仍然可以工作。
但是，如果使用严格验证，添加 Do-Z 后，旧客户端将无法使用新服务合同。事实上，即使操作完全相同，它也不适用于新合约；在这里，你可能会说旧合约和新合约 等价 （它们定义了完全相同的操作），但仍然 不一样，因为它们位于不同的名称空间下。