Web應用程序設計

Question

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

該項目設計為高度可伸縮的，並且易於完全獨立地維護業務對象。 易擴展性迫使某些設計決策阻礙了項目的初始效率。

基本設計如下。

有一個用ASP.NET MVC編寫的“核心”，它管理JSON API和HTML Web的所有交互。 但是，它不創建或管理“業務對象”，如“帖子”，“貢獻者”等。它們都在各自獨立的WCF Web服務中進行處理。

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

每個Web服務將在數據庫中管理相關的業務對象及其數據。 這里還將進行任何特定於業務的處理，例如將表中的數據映射到控件中使用的有用數據結構。 整個對象將傳遞給核心，並且核心應該僅在每個事務中檢索或設置一個業務對象一次。 如果將來需要進行多方面的操作，那么我將需要使該功能可用。

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

與我的朋友交談后，我有以下問題。

1. 我很欣賞WCF不如DLL調用或類似方法快。 但是整個系統基於它們會產生多少開銷？

2. 創建線程可能很昂貴。 這樣做會比僅一次調用所有控件花費更多嗎？

3. 您是否可以通過這種設計看到其他固有的凹坑？

Answer 1

除網站外，您還有其他任何Web服務客戶端嗎？ 如果是這樣，那么我認為確實不需要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傳輸 。 這樣可以避免客戶端和服務器位於不同計算機上時發生的所有必要的序列化和反序列化。

Answer 5

聽起來不像是高度可擴展的東西。 至少每秒不會有很多用戶。 通過創建比您需要的線程多得多的線程，隨處使用WCF會使速度變慢。 如果WCF調用做的工作不多，那么線程開銷會嚴重傷害您。 盡管它將是多線程的，但對ASPX頁面的多次調用已經是多線程的。 當一個人運行時，您可能會加快系統速度，但是如果有許多用戶在運行，則可能會嚴重影響性能。 例如，如果一個用戶請求該頁面，則多線程可能會獲得十個單獨的WCF調用。 但是，如果您每秒有100個頁面請求，則意味着每秒有1000個WCF調用。 那是很多開銷。