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

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

IExtensibleDataObject

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

IParameterInspector

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