我目前正在使用界面中定義的大量方法來處理WCF服務。這些方法中的大多數都是簡單的CRUD操作，只需使用實體框架的一些邏輯即可，並且可以很容易地將其分割爲功能區域。只有一個文件接近1K行代碼，我想分解它以提高可維護性。我正在考慮以下內容：什麼是在.NET WCF服務中組織大量方法的好方法？
此外，根據功能區域或CRUD方法（組合在一起，共同創建等）更好地分割。
這在處理WCF服務時必定是一個非常普遍的問題。什麼是組織WCF服務方法的好方法？
更新
最後，我決定通過內部靜態類的服務電話。
如果操作可以按功能區域分組，則它們應該是單獨的服務，因爲與其他任何類別的服務應該有單一職責=單一功能區域。
通常，如果您的服務有很多操作，現在是時候處理它的分裂問題了。另外，大多數情況下，WCF服務僅包含一些邏輯，因此您可以創建包裝邏輯的其他類的實例，或者在服務操作中使用靜態類。
編輯：
通常我反對使用部分類，打破了大類 - 在我看來，這並不能提高可維護性。一旦一個類如此之大，以至於你正在尋找將其分解成多個文件的解決方案，那就意味着很久以前就應該重構了。在最糟糕的情況下，當你的班級真的做得太多時，我們可以稱之爲反模式：God object。
我一般會同意。但是，我可以看到，在Web服務的情況下，可能會出現這種情況，我認爲它不一定傾向於上帝對象。在內部課堂上，這絕對是錯誤的。 –
@Schroedingers貓：這取決於。如果你的服務只是圍繞其他邏輯進行封裝，並且它暴露了一個功能區域的方法，那麼即使是擁有很多方法的大類也是有意義的。但是，如果服務實際上從多個功能區域執行邏輯，那麼它與內部類一樣糟糕。 –
爲了可維護性，使用部分類似乎是一個不錯的選擇。如果它們在功能上分離，那麼可維護性會提高，因爲您只需要查看這些類中的一個或兩個。
事實上，仍然有一個巨大的類與許多方法不是真正的問題根據你的答案。它應該是可維護的。
但是，要遵循@Ladislav，將它們分離爲單獨的服務有什麼價值嗎？我不假設，否則你會這樣做。
我沒有看到分裂成不同服務的任何價值。目前，這不是很多方法，但代碼開始增長，並且我想在它變得太大之前重構。 – Mas
這可能是想法分裂的時候。但是你比我更瞭解自己的代碼和環境，所以它是你的決定。 –
這取決於方法的性質 - 它們是否易於分組byt函數？他們有相似之處嗎？什麼是想要分裂它們的原因 - 可維護性，可更新性或什麼。答案會影響建議。 –
他們可以很容易地按功能區分組。拆分它們的原因是可維護性。 – Mas
大多數時候你開始考慮使用部分類，因爲你的班級變得太大，你知道是時候重構了。 – codymanix