WCF另一個最佳實踐？

Question

好吧，所以我建立了我的WCF服務，它的功能很棒！然而，我現在開始將它實現到我們現有的軟件中，並且我立即遇到了這個問題，我是否只使用代理生成的代碼並擺脫我最初使用的dll？或者我保留兩者，並且在兩者之間做出區分非常明顯？

我的意思是保持區別是有一個ServerUser和一個LocalUser屬性代表相同的用戶對象。但是，如果應用程序服務不可用，我的LocalUser屬性將通過應用程序初始運行的dll填充。

我這種思維模式的主要原因是，如果我刪除我的DLL，我有一個單點故障。如果由於某種原因，我的ServiceHost沒有啓動並運行，但是數據庫服務器，我希望我的用戶仍然能夠完成他們的工作。新的WCF實施所使用的功能並不依賴於員工的工作。這對WCF服務提供了更多便利。另外，通過構建服務的這種邏輯，可以在非IIS託管環境中更容易地使用服務修改。

此外，有沒有一種方法可以構建服務的邏輯，以便當我拉下客戶端的代理代碼時，只知道在ServiceHost不可用時手動訪問數據庫？如果這是一種可能性，我想大約90％的問題都會消失。

預先感謝您！

Answer 1

從描述中可以看出，保持現有的DLL即直接訪問數據庫最適合您的需求。有一個WCF服務不會添加任何內容，如果它失敗時，您將只使用該DLL。

理想情況下，您將完全使用WCF服務並提供某種冗餘來處理任何潛在的服務問題。另外，使用服務將意味着您不必處理任何DLL升級/部署。

但是，從你的問題來看，如果服務不可用，那麼聽起來好像會有一些真正的問題需要處理，所以只能使用DLL。

編輯：只讀了你的問題的最後一部分，我不認爲這是可能的。訪問服務的代理代碼是在向項目添加引用時生成的。你所追求的那種「動態」信息實際上需要一項服務。

編輯：作爲後續我的評論下面你可以通過創建一個DLL和類來測試這個，我們稱之爲Class1。然後用一個將返回Class1的方法創建一個WCF服務。創建一個客戶端應用程序並添加對該服務的引用。如果你看看代理生成的代碼，你應該看到（希望...我正在考慮這個，因爲我鍵入:)），該方法返回Class1，但是當你編譯它將無法找到Class1。這是因爲Class1沒有DataContractAttribute，它會在客戶端自動生成Class1。所以，你必須將共享DLL分發給客戶端。現在，當方法返回並且WCF嘗試重新創建Class1時，它將使用共享DLL中的本地版本。你的其他DLL，它將已經在客戶端上，將使用相同的共享DLL。