我目前正在開發一個應用程序，它在設計上有一個三層體系結構。它由一個管理網站，一個WCF Web服務和一個數據庫組成。當然，網站並不直接連接到數據庫，因此所有請求和響應都必須通過該服務。這個「問題」是有幾個實體參與了這個應用程序，並且對於其中的每一個我都必須支持基本的CRUD操作等等，這使得服務在單個端點中擁有超過30種方法。由於我已經不得不增加最大消息大小，所以我開始問自己是否在單一服務中使用所有這些方法並不是太多。你怎麼看？我有什麼替代方案？WCF-有多少種方法太多？
我真的不能給你一個很好的答案，因爲它取決於你的應用程序的要求和複雜性。通常，CRUDy服務界面是您應該避免的反模式。數據層和服務層之間不應該有一對一的映射關係。如果有的話，那麼服務層就不是拉扯自己的體重。 SOA是一個巨大的話題，我只是開始討論，但我的理解是SOA應該封裝許多操作的邏輯。即（認證，授權，記錄，縮放，交易等）
http://msdn.microsoft.com/en-us/library/ms954638.aspx
你聽說過Repository模式的？這是一種軟件設計模式，其中特定的類/程序集封裝了將數據導入和導出數據庫所需的邏輯。它的重量更輕，然後使用全面的服務，如果您想要的是將應用程序從數據庫中解耦的好方法，則可能是您需要的全部功能。 Repository模式的一個非常簡潔的功能是，您可以使Repository的所有方法成爲Interface，然後使MockImplementation在您的業務/ UI層上獨立於數據庫執行測試。
有沒有真正的具體回答這個問題。這是一種折衷方式。儘量保持單一責任原則。一對選項是：
通過WCF服務實現重複的CRUD功能可能會很痛苦，但如果服務沒有全局暴露（因此您不必爲認證/授權付出很多代價），您可以節省大量的通過使用以下兩種方法之一：ADO.NET數據服務或WCF RIA服務。
單個服務中的30個方法是否是一個糟糕的設計 - 這是不明確的。這就好比問一個有30名成員的班級是不是一個糟糕的設計 - 有些人會說這是絕對的，大多數人會評論「這取決於你在做什麼」。
儘管如此，對CRUD使用HTTP會帶來一些限制 - 您提到的其中一個限制。除非增加消息大小，否則無法插入/更新大批量。除非您以某種方式明確涉及通過http進行的事務，否則您還可能會遇到一些嚴重的事務處理問題。