WCF项目的锅炉板，预计将进行版本控制

问题描述

|| 我开始发现越来越多地将WCF用于我为内部使用而实现的项目（自动执行公司任务，确保所有客户都在同一页面上，等等）。这主要是由于3-10客户每当我实施解决方案时，我都会立即实现自动化，而且（即使是很小的样本量）公司也在不断发展，不断增加池中的更多客户，因此对可靠性/一致性提出了更高的要求。话虽如此，我已经意识到确保（随着以前的情况）推动发布变得越来越重要，因为我依赖于该服务的客户越多，推动发布变得越来越困难。 我最新的项目有被外部化的潜力。到现在为止，我已经按照已知的方式进行了工作，但是就将来的更新而言，我仍然想走“正确”的道路。我应该如何设置我的项目文件以使其尽可能简单和无缝，以保持维护，最新和扩展？我是否应该使用伪文件夹将版本号放入命名空间（如Company.Interfaces.Contracts.June2011.IMyService中）？ 我只是对前进的这方面没有信心。我想知道，无论我现在进行的基础工作如何，都不会给以后的扩展/定制带来负担。我也想尽可能坚持“开发规范”，因为越来越有可能我们会雇用更多的程序员来帮助工作。 有这种经验的人在这个领域有什么想法，建议和指导吗？我非常感谢您可以提供的任何示例，书籍，文档等。 更新（06-17-2011） 为了提供一些见解，我也在寻找一些特定的问题。这些包括： 您如何用名称空间来装饰服务类和DTO？我已经看到Service类本身使用了“ 0”，DTO中使用了“ 1”。这很常见吗？ （将名称空间分隔为类型和服务集合吗？） 我是否应该基于所有对象在将来发布时可能会演变成

IExtensibleDataObject

的想法？ （现在就做好基础工作） 如果我的数据库在（例如）字符串长度上有限制，我应该扩展

IParameterInspector

并使用该方法来确保有效性（保持逻辑和验证分开），对吗？ 应该将“实际服务”分解成自己的类，以便在我版本中，服务合同类仅调用代码（用最少的代码保持每个新版本的发布？）还是应该将其保留在服务类并使用任何新方法从该服务类继承（同样，应该删除一个方法会发生什么情况？） 很抱歉，如果我有很多问题，我只是在文档中看到了两个方面。我看到\“设置wcf \”，然后直接转到\“这是一个版本化的WCF \” –之间没有任何联系/步骤。我假设一旦获得足够的信息，它只会“点击”，但（不幸的是）我还没有。 tl; dr 当您开始编写WCF服务时，您知道它将经历多次迭代，如何设置您的项目，以使其在将来（对您自己和团队成员）尽可能地容易？     

解决方法

我已经成功使用了“严格的”版本控制策略（从过去的经验来看，无论如何您都朝着这个方向发展），每次发布新的定义时，您只需创建新的端点即可。这意味着您不会对旧版客户端有任何合约向后兼容性的担忧-一旦记录表明所有客户端都已升级，就可以轻松关闭旧版本。但是，通常有必要为任何旧式端点编写桥接代码，以便它们可以继续调用已修改的业务逻辑。 在项目组织方面，我将为每个版本创建一个新项目，以便可以轻松地分别部署它们。使用v1，v2的命名空间通常可以正常工作。端点名称还可以包含一个版本号，该版本号应易于区分它们。 或者，您可以尝试使用“宽松”版本控制策略，通过在所有服务中实现IExtensibleDataObject接口，可以添加或删除数据成员。在一个类似的问题的流行答复中，可以找到一些有用的MSDN文章链接：WCF客户端和版本控制。 另一种“松懈”的选择是将更多的精力转向消息传递解决方案（WCF可以通过消息契约和/或MSMQ绑定支持它）。 SOA专家Udi Dahan在这里播客，提供了一个有趣的观点，并且绝对值得一听-没有IDog2。 最后，这是一篇不错的博客文章，其中包含有关您最终使用哪种策略的更详细的准则：    http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/。