我开始发现自己越来越多地使用WCF来实现我为内部使用而实施的项目（自动化公司任务，确保所有客户都在同一页面上等）。这主要归功于3 -10客户端每当我实施解决方案时，我都会立即自动化，并且（即使它只是一个小样本）公司正在发展，这会不断增加池中的客户端数量，从而对可靠性/一致性提出更高的要求。话虽如此，我认识到确保我可以扩展的重要性是因为（以前）根据服务推动发布越来越多的客户越来越难。
我的最新项目有可能被外化。到目前为止，我已经按照我所知道的方式完成了这项工作，但我仍然希望在未来的更新方面沿着“正确”的道路前进。我应该如何设置我的项目文件，以使其尽可能简单和无缝地保持维护，更新和扩展？我应该将版本号放入命名空间（如在Company.Interfaces.Contracts.June2011.IMyService中），使用伪文件夹，......？
我对前进的这方面没有信心。我想知道，无论我现有的任何基础工作，都不会给以后的扩展/定制带来负担。我也希望尽可能地坚持“发展规范”，因为我们会聘请更多的程序员来帮助工作负载变得更加合理。
有这种经验的人有没有在这个领域的想法，建议和指导？我非常感谢您提供的任何示例，书籍，文档等。
为了提供一些见解，我也在寻找一些具体的问题。其中包括：
http://service.domain.com/ServerName/Version。这是常见的吗？ （将名称空间分隔为类型和服务集合？）http://types.domain.com/ServiceName/Version，因为它们可能会在将来发布时进化出来？ （立即解决问题）IExtensibleDataObject并使用该方法进行有效性（保持逻辑和验证分开），对吗？如果我有很多问题，我很抱歉，我只看到文档中的两个方面。我看到“设置wcf”然后直接“这是一个版本化的WCF” - 没有segue /步骤。一旦我得到足够的信息，我假设它只是“点击”，但我（遗憾地）还没有。
TL;博士
当你开始编写一个你知道将要进行多次迭代的WCF服务时，你如何设置你的项目以便将来尽可能简单（对你自己和队友）？
答案 0 :(得分：2)
我使用“严格”的版本控制策略取得了成功（从过去的经验来看，无论如何都是朝着这个方向前进），每次发布新定义时，您只需创建新的端点。这意味着您不会对旧版客户端产生任何合同向后兼容性问题 - 一旦日志记录表明所有客户端都已升级，就可以轻松关闭旧版本。但是，通常需要为任何遗留端点编写桥接代码，以便它们可以继续调用已修改的业务逻辑。
在项目组织方面，我会为每个版本创建一个新项目，以便可以轻松地单独部署。使用v1，v2的命名空间通常运行良好。端点名称还可以包含一个版本号，可以很容易地将它们相互区分开来。
或者，您可以尝试使用“宽松”版本控制策略，您可以通过在所有服务中实现IExtensibleDataObject接口来添加或删除数据成员。一些有用的MSDN文章链接可以在对类似问题的流行回复中找到：WCF client's and versioning。
另一种“松懈”的选择是更多地转向消息传递解决方案（WCF可以通过消息合同和/或MSMQ绑定来支持）。这里由SOA大师Udi Dahan播客提供了一个有趣的视角，绝对值得倾听 - there is no IDog2。
最后，这是一篇很好的博客文章，其中包含一些更细粒度的指导原则，指导您最终使用的策略： http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/