面向服务的体系结构和应用程序之间共享的进化对象

Question

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

不幸的是，我没有足够的时间编写一整套服务然后重新分解应用程序以使用它们，这将是一个随时间推移的迭代过程。我的问题是围绕不断发展（更改，添加，删除属性）业务对象。

例如：如果您有一个SOA公开一个返回obj1的服务。 app1，app2，app3正在使用该服务。想象一下，对于app1更改了对象，我不想更新app2和app3以进行对app1所做的更改。如果更改是一个添加属性，它将正常工作，它将不会被映射，但删除属性时会发生什么？或者将属性从字符串更改为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实施”的一个很好的流程图，可能有所帮助。