wcf - 面向服务的体系结构和在应用程序之间共享的不断发展的对象

Question

我即将开始为各种业务应用程序编写一套 WCF 服务。这个 SOA 一开始会非常不成熟，最终会演变成一个强大的中间件层。

不幸的是，我没有编写全套服务然后重构应用程序以使用它们的奢侈，这将是一个随着时间的推移完成的迭代过程。我的问题是围绕发展（更改、添加、删除属性）业务对象。

例如：如果您有一个 SOA 公开一个返回 obj1 的服务。app1、app2、app3 正在使用该服务。想象一下，app1 的对象已更改，我不想为 app1 所做的更改更新 app2 和 app3。如果更改是添加属性，它将正常工作，它根本不会被映射，但是当您删除属性时会发生什么？或者将属性从字符串更改为 int？你如何管理变化？

提前感谢您的帮助？

PS：我确实做了一张小照片，但显然我需要 10 的声望，所以你必须发挥你的想象力......

Answer 1

目标是限制您强迫客户必须立即做出的改变。他们最终可能不得不做出一些改变，但希望这只是在不可避免的情况下，比如他们落后了多个版本，而你正在完全淘汰它。

非破坏性更改可以是：

1. 添加可选属性
2. 添加新操作

重大变化包括：

1. 添加所需的属性
2. 移除属性
3. 更改属性的数据类型
4. 更改属性名称
5. 删除操作
6. 重命名操作
7. 如果明确指定，则更改属性的顺序
8. 更改绑定
9. 更改服务命名空间
10. 改变操作的意义。例如，我的意思是，如果操作总是返回所有记录，但它被更改为只返回某些记录。这会破坏客户的预期反应。

选项：

1. 添加一个新操作来处理更新的属性和逻辑。如果可以，修改原始操作后面的代码以设置新属性并重构服务逻辑。只要记住不要改变操作的含义。
2. 如果您想要删除不再想要支持的操作。您正在迫使客户必须在某个时候进行更改。您可以在 wsdl 中添加文档，让客户知道它已被弃用。如果您让客户使用您的合同 dll，您可以使用 [Obsolete] 属性（它不是在最终 wsdl 中生成的，所以这就是为什么您不能只使用它的原因）
3. 如果它完全是一个大的变化，一个新版本的服务和/或接口和端点可以很容易地创建。即v2、v3等。然后你可以让客户端在适当的时候升级到新版本

这也是来自“Apress - Pro WCF4：实用的 Microsoft SOA 实施”的一个很好的流程图，它可能会有所帮助。