目前我們在解決方案中有12個WCF項目。每個項目本質上都是自己的終端。例如,「Order」WCF項目是Order.svc端點。這12個端點由單個WebHost項目公開。 WebHost項目有12個.svc文件指向每個相應的程序集/名稱空間。多個WCF項目與解決方案中的單個項目
我的問題圍繞使用一個項目(一個程序集...一個DLL)vs多個項目(多個程序集...多個DLL)。有什麼優點/缺點?最終的結果是一樣的......你有一個WebHost項目公開了這些端點指向一個程序集/名稱空間。除非你只需要在bin目錄下管理一個.dll和12個.dll文件。
對我的優勢,一個項目: 維修 - 而不是12個項目,每個到我們的接口,datacontracts,公用事業等多個引用,我們已經在一個地方集合中引用一個項目。然後,我們可以部署一個DLL並利用負載平衡器來均勻分配。即使我們明確地爲每個服務器(如此,4個服務器)託管3個服務,但如果服務器關閉,負載均衡器可以調整,其他3個服務器將擁有他們需要的並自動處理所有事情。 (我想對於.dll文件也是如此......只需確保所有12個.dll文件位於每臺服務器上即可)。
構建時間 - 更少的項目=更快的構建時間。 Visual Studio不必執行儘可能多的鏈接和複製.dll遍佈整個地方。更快的構建時間=更高效的開發人員和更快的構建和部署。
我目前有幾個同事關心將我們所有的WCF服務「緊密地」結合到一個項目中。對我來說,他們都是WCF服務,爲什麼不把它們放在同一個項目中?端點(.svc文件)是將它們分開的東西。我也聽到了這個問題:「死鎖怎麼辦?」。那它呢?這是一個有效的問題/關注嗎? (我真的不知道)
也有人提出有關如果.dll變得腐敗的問題。如果是,那麼所有的服務都停止了。再次...這是一個有效的關注?
我從Microsoft和其他人那裏看到的所有例子都有一個項目中的WCF服務,它們由不同的類隔開。接口在他們自己的項目中......在另一個項目中的數據合同等等。
那麼,你需要什麼?如何在Visual Studio解決方案中組織多個WCF服務?向我學習。