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