如何避免WCF中的巨大通信類？

我的理解是，所有契約實現代碼必須在一個類中，顯然它可能變得非常大。我如何避免這種情況？我真的更喜歡有幾個小班做與客戶溝通的一部分，而不是一個龐然大物的班級。如何避免WCF中的巨大通信類？

我能想到的唯一想法是使用由單個類實現的多個接口，分解爲partial，但我不認爲這真的解決了問題。

來源

2010-03-15 mafu

首先，如果您的合同很大，他們是否可以重構爲更具體的服務合同？

契約實現類可以作爲入口點方法實現。您始終可以對實現進行建模並定義適當的抽象，並讓您的服務合同實現類調用這些內部實現。

來源

2010-03-15 10:23:01

準確無誤 - 沒有單一的超強服務合同 - 將其分成可管理的區塊。那麼服務實現也不會太大！ – 2010-03-15 10:30:16

多個合同意味着多重連接，對嗎？我寧願避免這種情況。 – mafu 2010-03-15 12:58:19

每個將不得不被託管在不同的地址，因此需要不同的代理連接，如果這就是你的意思。如果你試圖避免這種情況，那麼重構你的內部實現來使用像其他答案中建議的繼承或外觀模式。 – 2010-03-15 13:44:00

'單班'通常是一個門面，只是一個溝通的前端。
所以你應該而不是所有你的邏輯在Service實現者中實現。

而你的接口應該儘可能小（做一件好事）。但如果需要，您的門面可以打電話給多個班級。

來源

2010-03-15 10:20:21

是的，當然，但班級仍然非常大，所以我想以某種方式將其拆分... – mafu 2010-03-15 12:59:34

這意味着您有一個'安靜大「的界面，也許是一個設計問題。 – 2010-03-15 13:05:47

您可能想要使用Inheritance，這取決於yoru代碼的結構。通常你可以將所有的代碼分解成小塊，輔助函數，子例程等。

這就像其他任何API開發一樣，你不想/不需要/不需要在同一個地方的所有東西包。

來源

2010-03-15 10:20:37

我們有大約60個稱爲「BeamServer.cs」的部分文件，每個文件位於與該文件中功能的用途對應的子文件夾中。我們程序的同一區域的任何助手類（或其他幫助程序文件）也駐留在該文件夾中。

您的「一類」代表您的「一項業務需求」。我們發現了一個很好的副作用，如果我們團隊的成員之一正在研究BEAM（我們的軟件）的「會計」部分，那麼他們將檢出文件「Accounting \ BeamServer.cs」，其餘部分的隊伍將受到影響。

編輯：另外，每班應僅包含的方法簽名（及包裝函數去調用base.Channel.DoSomething() ...任何數據結構當然會是他們自己的類文件（如「Person.cs」或「 Employee.cs「或其他）

來源

2010-03-15 10:24:34

我繼續嘗試部分課程，但不幸的是，VS08並沒有很好的支持，所以我放棄了這個想法。 :( – mafu 2010-03-15 13:00:54

如果你可以從根本上改變你的代碼，你可以公開一個單一的端點來處理請求/響應消息，這樣可以有一個單一的端點和一個單一的服務定義它接受一個（可能派生的）請求消息並返回一個響應消息，然後你的接口進入服務將只是一個單一的方法，在服務器端的實現中，你可以將請求對象路由到實際的服務i （可能由工廠決定）可能使用請求消息的元數據（甚至是'type-name'）來定義正在調用的服務。

那麼，您的最終服務接口也只是有這樣的方法：

public interface IServiceRequestor 
{ 
    Response ProcessRequest(Request request); 
}

這可以讓你處理的暴露服務可能無限數量，而不必知道他們會在編譯什麼的/ dev時間，同時也避免了定義可用服務呼叫的服務方法的擴散

來源

2010-03-15 14:50:48 saret

這當然相當激進，但將類似方法結合起來的總體思路是很好的。 – mafu 2010-03-16 09:06:02

如何避免WCF中的巨大通信類？

回答

相關問題