Web應用程序設計

Question

我有一個項目，我最近開始認真工作，但與朋友進行了一些設計討論，我想他提出了一些有趣的觀點。

該項目旨在具有高度可擴展性，並易於完全獨立地維護業務對象。易於擴展性迫使一些妨礙項目初始效率的設計決策。

基本設計如下。

在ASP.NET MVC中有一個「核心」，它管理着所有的交互JSON API和HTML網頁。然而，它不創建或管理像發佈，貢獻者等「業務對象」。這些都是在他們自己單獨的WCF Web服務中處理的。

核心的想法是非常簡單的，利用單獨的控件使用管理對象從Web服務檢索業務數據/對象。這又意味着核心可以是多線程的並且可以同時調用頁面上的控件。

每個Web服務都將管理數據庫中的相關業務對象及其數據。任何業務特定的處理也將在此處，例如將表中的數據映射到用於控件的有用數據結構。整個對象將被傳遞到核心，核心應該只是每個事務檢索或設置一個業務對象。如果將來需要多重影響的操作，那麼我將需要提供該功能。

此外，Web服務可以執行自己的獨立緩存，並根據請求以及他們自己對其特定區域的知識（例如用戶）可以返回新創建的對象或預先創建的對象。

與朋友談話後，我有以下問題。

1. 我明白，WCF不如DLL調用或類似的東西快。但是，整個系統是以多少開銷爲基礎的？

2. 創建線程可能很昂貴。比起只是一個接一個地調用所有的控件，花費更多嗎？

3. 在這個設計中你可以看到有其他的內在坑嗎？

Answer 1

您是否有其他客戶用於網站之外的網絡服務？如果是這樣，那麼我認爲Web服務並不是真的需要。服務接口是合理的，但這並不意味着它需要成爲Web服務。使用Web服務會導致額外的串行化開銷和一次數據網絡傳輸。您可能獲得了一些針對您的服務的自動緩存功能，但您似乎打算在任何情況下自行實施此功能。由於我們不知道你的對象有多複雜，你打算傳輸多少數據，所以很難量化開銷的數量，但我敢打賭，這不是微不足道的。

它是我，我會簡化設計：去單線程，使用嵌入式服務接口。然後，如果性能是一個問題，我會看看我可以通過緩存，多處理等解決現有性能問題的位置。這可以讓實際的應用程序驅動設計，儘管在性能方面仍然可以應用良好的模式和實踐發佈莊稼。如果性能不成問題，那麼你還沒有建立很多複雜的基礎設施 - YAGNI！你不會需要它！

Answer 2

1. 這要看你的服務調用的粒度。 SOA中的一個原則是使你的接口不那麼健談，即有一個調用執行一大堆操作。如果您將服務接口設計爲管理員業務對象，那麼它很可能會過於瑣碎。

2. 這取決於您的使用模式。關於線程，粒度也是一個關鍵因素。

3. 它看起來非常像你過度設計系統。改變一個服務接口比改變一個簡單的方法簽名要麻煩得多。如果所有的業務對象都作爲服務公開，那麼你需要做一個調試噩夢。

Answer 3

1。 如果您有一個或多個非本地客戶端（無法直接訪問您的邏輯），則面向Web服務的設計是合理的。例如AJAX，Flash，來自不同領域的另一個Web應用程序等等。但是，當您可以直接調用您的邏輯時使用WCF爲您的應用程序是非常糟糕的主意。

如果稍後您需要Web服務，您可以使用Service Layer輕鬆包裝域模型。

2. 在必要時使用線程池來最小化線程創建調用。關於這個問題的答案取決於你需要達到什麼，從你的解釋中不清楚。

3. 主坑摔倒是你試圖用於很多事情。過度設計可能是一個很好的術語。

Answer 4

如果您擔心調用WCF服務的開銷，那麼您可以使用null transport。這避免瞭如果客戶端和服務器在不同的機器上會發生的所有必要的序列化和反序列化。

Answer 5

這聽起來不像是具有高度可擴展性的東西;至少，而不是每秒很多用戶。通過創建比您需要的線程更多的線程，WCF中的所有東西都會讓事情變得緩慢。如果WCF調用沒有做太多的工作，那麼線程的開銷會讓你很難受。雖然它將是多線程的，但對ASPX頁面的多次調用已經是多線程的。只有一個人在運行時，你可能會加速你的系統，但如果有很多用戶在運行，就會很難達到性能。例如，如果一個用戶請求這個頁面，那麼十個獨立的WCF調用可能會從多線程中獲得。但是，如果每秒有100個頁面請求，那麼每秒就有1000個WCF調用。這是很大的開銷。