共享客户端和服务器的WCF合同

Question

有2个团队在开发产品。一个团队正在研究服务器端逻辑，作为WCF服务公开，另一个团队正在致力于实现前端（ASP.NET MVC网站）。在这两个团队之间共享服务API的适当解决方案是什么？通过API我的意思是一个Web服务接口+一堆DTO类。我们正在使用git和TeamCity进行持续集成。服务和前端是独立开发和部署的。

基于此，我看到的选项是：

1. 将所有“接口”内容放入一个单独的项目中，并通过git模块共享。客户端和服务器都将共享代码。
2. 将所有“接口”内容放入一个单独的项目中，并将其发布到私有NuGet存储库。客户端和服务器都将引用唯一的通用程序集。
3. 将客户端和服务器都放到单个VS解决方案中并按字面分享程序集。

选项3感觉就像最简单的方法，易于实现和理解，但我对获得更大解决方案的整个想法并不感到兴奋。选项1和2感觉非常相似，但我更喜欢选项2。

您认为这是一种更好的方法吗？还有其他解决方案吗？

Answer 1

我们使用选项4 - 客户端和服务器位于不同的解决方案中，但两个解决方案都包含相同的WCF合同项目（仅包含[DataContract]和[ServiceContract]定义）并使用项目引用而不是装配参考。这可能听起来很有趣，但它的工作正常。

两个解决方案都可以单独构建，并且它们都获得相同的DLL，因为无论它们内置了哪个顺序，第二个构建都不会重新编译DLL，因为它已经是最新的。

我认为这样做的主要优点是，当有人对合同项目进行源代码更改时，客户端和服务器代码都可以立即获得更改，而无需“刷新”任何内容。这削减了诸如“我做了做出改变”，“没有你没做”，“是的我做了”，“好吧我无法看到它”这样的论点。等等。

Answer 2

我们将公共代码存储在单独的解决方案中。它生成.dll，它们作为一个简单的程序集引用添加到依赖于它们的多个其他项目中。

所有构建都在nant文件中定义，并且我们有一些.bat文件以适当的顺序运行构建。

当你只想从VS构建项目时，很可能已经构建了依赖的.dll。如果你想成为100％你有一切都是用最新的变化构建的，你运行那些将触发nant构建并重建所有内容的bat脚本。

Answer 3

在我的项目中，我们使用了与您在选项1共享代码

中描述的方式类似的方式