共享客戶端和服務器的WCF合同

Question

有兩個團隊正在研究產品。 一個團隊正在研究服務器端邏輯，作為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共享代碼中描述的類似方式