將Web服務用作.NET中數據訪問層的接口

Question

我目前正在為學校做一個CRUD項目，基本上他們希望我們擁有這種結構（3個項目）：

這基本上意味着我們無法直接從網站訪問類庫：

Website
       \
        \
         Web Service
                    \
                     \
                      Class Library

當然，現在有多種解決方案可供選擇，以在Web服務中提供抽象以分離例如檢索文章的方法和檢索類別的方法（這是兩個不同的入口，並且在類庫中有兩個單獨的類）：

我可以做一個將具有所有方法（GetAllArticles，GetAllCategories，GetArticleByID等）的Web服務，並且網站僅引用此Web服務。 但這當然會導致所有方法都在一個類（即單個Web服務）中
或者，我可以創建多個Web服務（ Articles.asmx ， Categories.asmx等），然后從網站上引用所有這些服務，然后根據需要檢索的數據調用所需的服務。

但是對於我來說，上述解決方案並不是真正理想的解決方案，因為如果我有第一個解決方案，那么我將在一個類中擁有大量方法（無論什么都不抽象），而在第二個解決方案中，我將不得不引用約10個方法網站提供的不同Web服務（一項用於文章，一項用於類別，等等）

在學校里，他們告訴我們使用Web服務（或Web服務）訪問類庫，然后使用Web方法從類庫中檢索數據，但是我前面提到的兩種解決方案似乎都有些晦澀。

有沒有更好的方法可以實現這種結構？

Answer 1

在您的示例中，您為文章建議了一項服務，為類別建議了一項服務。 當然，這可能只是一個例子，但是在這種情況下，將它們分開是沒有意義的，因為使用類別數據和商品數據的查詢和/或例程很有可能且很常見。

考慮到這一點，通常最有意義的是按例程之間的關聯程度對其進行分組。 如果您可以將所有可能的例程分成三個幾乎沒有重疊的干凈組，那么擁有三個服務就很有意義。 如果您無法徹底分離任何例程，則應將自己限制為一個Web服務。

但是關於您的聲明“ No abstraction”是一個Web服務的缺點-不一定是正確的。 您始終可以在Web服務之后創建抽象層，以便服務類本身只是具有許多瘦方法調用的基礎，而這些方法調用可進入其他地方的更大邏輯。

最后，真正重要的唯一方法是，它是唯一有效的方法，它是： 盡可能采用最簡單的方法，只構建所需的內容，並盡可能地減少層數。 僅當遇到無法通過增加復雜性來解決的問題時，才增加復雜性。 增加復雜性總是比消除復雜性總是容易的。

Answer 2

我會將所有網絡方法都放在同一個類中。 Web方法僅應包裝在您的業務類周圍，再加上您需要的任何輸入驗證和授權。

由於Web服務通常由機器人而不是人類使用，因此迫切需要層次結構。 如果您為每個業務類創建一個Web方法類，則可能成為管理URL和Web服務器的負擔。

如果您打算使用瀏覽器自動生成的HTML頁面作為主用戶界面來調用Web服務，則需要多加注意。 例如，如果您需要對請求進行身份驗證，則將無法依賴SOAP標頭。

Answer 3

為什么不使用ADO.Net數據服務？