設計：網站在同一臺機器上調用web服務

更多的設計/概念問題。設計：網站在同一臺機器上調用web服務

在工作中，決定讓我們的數據訪問層通過webservices調用。所以我們的網站會調用webservices來處理數據庫中的任何/所有數據。 Web服務的網站&將位於同一臺計算機上（因此不會穿越網線），但該數據庫位於單獨的計算機上（因此無論如何都需要跨網線旅行）。這是全部內部的，網站，網絡服務和數據庫都在同一家公司內（AFAIK，網絡服務不會被另一方重複使用）。

據我所知：該網站將打開一個端口到webservices，並且webservices將打開另一個端口並通過網絡連接到數據庫服務器以獲取/提交數據。穿越電線的旅程是不可避免的，但我擔心站在中間的Web服務。

我同意需要在功能（如業務層，數據訪問層等）之間有不同層次，但這對我來說似乎過於複雜。我也感覺到會有一些性能問題。

在我看來，最好是在解決方案中直接引用（DAL）程序集，從而否定第一個端口到端口的連接。

支持和反對這個想法既任何想法（或鏈接），將不勝感激

附：我們是一個.NET商店（從vb遷移到C＃3.5）

編輯/更新標記Dathan作爲答案，我仍然沒有完全銷售（儘管傾斜它，我依然沒有完全賣掉沒有我擔心的那麼糟糕），他提供了一個深思熟慮的答案。我讚賞所有的反饋意見。

來源

2010-03-22 Chris L

不使用網絡服務作爲您的DAO的鏈接。這對你的代碼以及你的web服務器來說是一個巨大的性能影響。爲什麼要添加該圖層？所以你可以使用AJAX調用來打DAO？你真的想讓你的用戶界面直接與你的DAO對話嗎？ Bad move，imho – hunter

兩種設計（應用程序到Web服務到數據庫;應用程序到數據庫通過DAL）是非常標準的。 Web服務通常用於與客戶端連接以標準化數據訪問的語義。 Web服務通常能夠比基礎持久性存儲更準確地表示數據模型的語義，從而通過抽象和封裝IO特定問題來幫助系統的可維護性。Web服務還提供了通過防火牆通常可訪問的協議提供公共接口（儘管「公開」可能仍然意味着公司內部）到您的數據的額外目的。當使用DAL直接連接到數據庫時，可以用類似的方式封裝數據IO問題，但最終客戶端必須直接訪問數據庫。通過將IO限制在明確定義的語義（通常是CRUD + Query）中，您可以添加額外的安全層。這對你來說並不是什麼大事，因爲你正在運行一個web應用程序 - 所有的數據庫訪問都是從可信的代碼完成的。儘管如此，Web服務確實提高了針對SQL注入的健壯性。

所有Web服務的理由之外，真正的問題是：

這多少會使用嗎？網站/網絡服務/數據庫格式確實會在網絡服務器上造成稍高的開銷 - 如果網站遭受攻擊，您希望在將另一項服務放在同一臺計算機上之前考慮花費很長時間。否則，增加的低效率可能不是什麼大不了的事情。另一方面，如果網站受到重擊，那麼您可能想要橫向擴展，並且您應該能夠同時擴展Web服務。

你獲得多少錢？擁有Web服務的一個重要原因是爲客戶端代碼提供數據訪問能力 - 特別是在需要支持多種可能的應用程序版本時。由於您的Web應用程序是使用Web服務的唯一客戶端，因此這不是一個問題 - 它本身可能不太需要對應用程序進行版本控制。

您是否想要擴大？你說它可能永遠不會被任何客戶使用，除了單一的網絡應用程序，但這些東西有一個獲得規模的方式。如果您的網絡應用程序有可能在範圍或流行度上增長，請考慮Web服務。通過圍繞Web服務進行設計，您已經瞄準了一個模塊化的多主機解決方案，因此您的應用程序可能會以較少的成長困難來擴展。

如果你不能猜到，我是一個Web服務粉絲。但上述也是我對這個問題的誠實（如果有些偏見）的意見。如果你確實去了Web服務路線，一定要簡單一些 - 將應用程序邏輯保留在服務中的應用程序和服務邏輯中，並且在擴展它們時儘量在它們之間畫一條明亮的線。並設計您的服務以提高效率，並配置託管以保持其運行順暢。

來源

2010-03-22 19:27:50 Dathan

@Dathan：爲什麼Web服務比帶有與Web服務相同接口的DAO更有幫助？另外，我可能不希望我的客戶訪問我在應用程序中使用的相同數據訪問權限。我可能希望保留某些操作，甚至是數據庫的整個部分，供我自己使用，而不是將它們暴露給客戶。 –

@John我在回答中指出，就界面和職責分離而言，Web服務與設計良好的進程內DAL沒有實際區別。根據我的經驗，網絡服務可以更好地擴展。對於功能，我假設「不要將它們暴露給我的客戶」，你的意思是你會發布缺乏這些功能的DAL？ Web服務通過身份驗證和授權提供相同的功能。您可以通過授權限制發佈的元數據和實際可訪問的功能，而無需維護DAL的兩個不同版本。 FTW。（C： – Dathan

@Dathan：我提供給我的客戶的數據視圖可能與我在我的網站上使用的數據不同，我的DAL顯然會爲我提供我需要的一切，就規模而言，我很樂意看到數字考慮相同數量的實際數據庫服務器，服務和等效DAL之間的差異 –

我喜歡這個想法，因爲它給你靈活性。我們使用一種非常相似的方法，因爲根據我們的客戶安裝選擇，我們可以有多種類型的數據庫存儲我們的數據（MSSQL或Oracle）。

如果客戶選擇不使用我們的前端網站，它還可以讓我們掛鉤到我們的數據庫。因此我們獲得了一個開放的API，只需要很少或沒有額外的努力。

如果速度是您最關鍵的問題，那麼您必須縮小層數。但是在大多數情況下，Web Service處理來自數據庫的請求所花費的時間並不會增加時間。（這是假設你做你的Web服務層正確，你可以輕鬆地讓它慢，如果你不看它。）

來源

2010-03-22 19:17:24

嚴，你可以有多種類型的數據庫，而不使用這種Web服務額外的層次方法。 – systempuntoout

+1此外，這使應用程序更容易擴展;如果需要的話，很容易分開層，甚至可以在兩者之間添加一些負載平衡。 – CodingInsomnia

@systempuntoout Yesyou可以。特別是對於NHibernate，但我們沒有得到快速API，這是服務的主要原因。 –

這是有問題的設計，但你的店是不使用它的唯一的一個。

由於您使用的是.NET 3.5並且運行在同一臺機器上，因此您應該使用WCF netNamedPipesBinding，它使用通過命名管道進行二進制數據傳輸，僅在同一臺計算機上。這應該會緩解性能問題。

來源

2010-03-22 19:20:43

設計：網站在同一臺機器上調用web服務

回答

相關問題