用于WCF项目的锅炉板,预期版本化

Question

我开始发现自己越来越多地使用WCF来实现我为内部使用而实施的项目(自动化公司任务,确保所有客户都在同一页面上等).这主要归功于3-10个客户每当我实施解决方案时,我都会立即实现自动化,并且(即使它只是一个小样本)公司正在发展,不断增加池中的客户数量,从而对可靠性/一致性提出更高的要求.话虽如此,我认识到确保我可以扩展的重要性是因为(以前)根据服务的不同,推出一个版本的客户越来越多.

我的最新项目有可能被外化.到目前为止,我已经按照我所知道的方式完成了这项工作,但我仍然希望在未来的更新方面沿着"正确"的道路前进.我应该如何设置我的项目文件,以使其尽可能简单和无缝地保持维护,更新和扩展？我应该将版本号放入命名空间(如在Company.Interfaces.Contracts.June2011.IMyService中),使用伪文件夹,......？

我对前进的这方面感到不自信.我想知道,无论我现有的任何基础工作,都不会给以后的扩展/定制带来负担.我也希望尽可能地坚持"发展规范",因为我们会雇用额外的程序员来帮助工作负载变得更加合理.

有这种经验的人有没有在这个领域的想法,建议和指导？我非常感谢您提供的任何示例,书籍,文档等.

---

更新(06-17-2011)

为了提供一些见解,我也在寻找一些具体的问题.这些包括:

1. 如何在命名空间方面修饰服务类与DTO？我已经看到http://service.domain.com/ServerName/Version在Service类本身http://types.domain.com/ServiceName/Version使用并在DTO上使用.这是常见的吗？(将命名空间分隔为类型和服务集合？)
2. 我是否应该IExtensibleDataObject在所有对象上实施,因为它们可能在将来发布时进化？(立即解决问题)
3. 如果我的数据库对(例如)字符串长度有限制,我应该扩展IParameterInspector并使用该方法进行有效性(保持逻辑和验证分开),对吗？
4. 是否应该将"实际服务"分解到自己的类中,因此,正如我的版本所示,服务合同类只调用代码(尽可能使用最少的代码保留每个新版本？)或者我应该将其保留在服务中class并使用任何新方法继承它(同样,如果删除方法会发生什么？)

如果我有很多问题,我很抱歉,我只看到文档中的两端.我看到"设置wcf"然后直接"这是一个版本化的WCF" - 没有segue /步骤.一旦我得到足够的信息,我假设它只是"点击",但我(遗憾地)还没有.

---

TL;博士

当您开始编写一个您知道将要进行多次迭代的WCF服务时,如何设置项目以使其在未来(对您自己和队友)尽可能简单？

Answer 1

我已经成功地使用了“严格”​​的版本控制策略（从过去的经验来看，无论如何你都会朝这个方向前进），每次发布新定义时，你只需创建新的端点。这意味着您不会对旧客户端有任何合同向后兼容性问题 - 一旦日志记录表明所有客户端都已升级，旧版本就可以轻松关闭。然而，通常有必要为任何遗留端点编写桥接代码，以便它们可以继续调用修改后的业务逻辑。

在项目组织方面，我会为每个版本创建一个新项目，以便可以轻松地单独部署它们。使用 v1、v2 的命名空间通常运行良好。端点名称还可以包含版本号，以便轻松区分它们。

或者，您可以尝试使用“宽松”的版本控制策略，通过在所有服务中实现 IExtensibleDataObject 接口，您可以添加或删除数据成员。一些有用的 MSDN 文章链接可以在对类似问题的流行回答中找到：WCF 客户端和版本控制。

另一种“宽松”的选择是更多地转向消息传递解决方案（WCF 可以通过消息契约和/或 MSMQ 绑定来支持）。SOA 大师 Udi Dahan 的播客提供了一个有趣的视角，绝对值得一听 -没有 IDog2。

最后，这是一篇很好的博客文章，其中包含有关您最终使用哪种策略的更细粒度的指南： http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/。