WCF工程锅炉板，预计版本

Question

我开始越来越多地将WCF用于我为内部使用实现的项目(自动化公司任务，确保所有客户都在同一个页面上，等等)。这在很大程度上是因为，每当我实现解决方案时，我都会同时自动化3-10个客户端，而且(即使是一个小样本)，公司在不断增加客户的数量，从而对可靠性/一致性提出了更高的要求。尽管如此，我认识到确保事情可扩展是多么重要，因为(以前)推动发布的客户越多，取决于服务的客户就越多。

我最近的项目有可能被外化。到目前为止，我一直以我所知道的方式工作，但我仍然希望在未来的更新中走上“正确”的道路。我应该如何设置我的项目文件，使这尽可能容易和无缝，以保持维护，最新和扩展？我是否应该将版本号放在名称空间中(就像在Company.Interfaces.Contracts.June2011.IMyService)，中使用伪文件夹，.)？

我只是对这方面的进展没有信心。我想知道的是，我现在所做的任何基础工作都不会给以后的扩展/定制带来负担。我还想尽可能地坚持“开发规范”，因为我们会雇佣更多的程序员来帮助完成工作。

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

更新(06-17-2011)

为了提供一些见解，我也在寻找一些具体的问题。其中包括：

1. 如何从名称空间的角度来装饰服务类和DTO？我见过在服务类本身上使用http://service.domain.com/ServerName/Version &在DTO上使用http://types.domain.com/ServiceName/Version。这很常见吗？(将命名空间分隔到类型和服务集合中？)
2. 我是否应该在我的所有对象上实现IExtensibleDataObject，因为它们可能在将来发布时得到进化？(现在把地面工作做好)
3. 如果我的数据库对它有限制(例如)字符串长度，我应该扩展IParameterInspector，并使用该方法的有效性(保持逻辑和验证分开)，对吗？
4. 应该将“实际服务”分解到它自己的类中吗?因此，正如我的版本一样，服务契约类只是调用代码(使每个新版本发布的代码尽可能少)？或者我应该将它保存在服务类中，并使用任何新的方法从它继承(同样，应该删除一个方法会发生什么？)

如果我有很多问题，我很抱歉，我只是在文档中看到了两头。我看到“设置wcf”，然后直接到“这是一个版本WCF”我假设一旦我得到足够的信息，它就会“点击”，但我(遗憾的是)还没有到那里。

tl；博士

当您开始编写WCF服务时，您知道它会发生几次迭代，您如何设置您的项目，使它在未来尽可能容易(对自己和队友)？

Answer 1

我已经成功地使用了“严格”版本控制策略(从过去的经验来看，您无论如何都在朝着这个方向前进)，每次发布新定义时，您只需创建新的端点/s即可。这意味着您不会对遗留客户端有任何向后兼容的考虑--一旦日志记录显示所有客户端都已升级，就可以很容易地关闭旧版本。但是，通常需要为任何遗留端点/s编写桥接代码，以便它们能够继续调用修改后的业务逻辑。

在项目组织方面，我会为每个版本创建一个新的项目，这样它们就可以很容易地单独部署。使用v1和v2的命名空间通常工作得很好。端点名称还可以包含一个版本号，该版本号可以很容易地区分它们。

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

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

最后，这里有一个很好的博客文章，它提供了一些关于您最终使用的策略的更细粒度的指导方针：http://wcfpro.wordpress.com/2010/12/21/wcf-versioning-guidelines-2/。