Web服務的可擴展性框架/模式/良好實踐？

我目前正在研究一個大型的實時OLAP應用程序。所有數據都保存在RAM（幾千兆字節）中，常見任務包括對大量數據進行強力掃描（這很好）。處理結果通過Web服務（singleton/multithreaded）公開，並使用基於Silverlight的客戶端呈現。Web服務的可擴展性框架/模式/良好實踐？

問題是，各種客戶需要不同的功能/算法，我不知道如何在服務器端提供可擴展性。對於客戶端（Silverlight），我可以使用MEF/Prism，但我不確定在服務器上解決此問題的好方法是什麼。

請注意，理想情況下，其他網絡服務應直接訪問（即不包含封送）到保存大數據模型的主要/當前服務的數據。

是否有：

一）框架/庫

B）模式

三）良好pracitces

，這將有助於我模塊化的應用程序，並期望選擇模塊和他們的部署相對容易？

來源

2010-06-21 Karol Kolenda

因此，您肯定希望在數據所在的服務器上運行不同的算法，並且調用者（通過Web服務）應該可以選擇指定哪個算法使用？它是否像一個工作流程概念，他們可能在不同的序列中使用多種算法？ – 2010-06-22 23:53:23

是的。我們只是給了我們的客戶一套方法，他們可以鏈接在一起並將其作爲工作流程運行。問題是我們可以有多個模塊，我們不太確定如何使它們在Web服務端可插入。 – 2010-06-24 09:55:43

對我來說聽起來像是需要依賴性反轉：通過定義接口來隔離系統的邏輯部分（算法等），然後使用DI/IoC框架在運行時（或在應用程序啓動等時）加載所需的實現。。

我還沒有使用過Ninject，但很多人都喜歡它，所以你可以嘗試一下;還有Spring.Net。

良好做法：

確保您有清晰準確的記錄，讓你知道什麼正在使用和時間。
想想你是否想要一個'默認'的實現加載，如果所需的一個失敗，或者你故意想失敗，以便不會錯誤地返回錯誤的數據（例如使用不同的algorythm）。
我發現使用屬性來裝飾注射模塊真的很有用（特別是在一個基於網絡的系統中，你沒有直接訪問），原因之一是你可以創建頁面或控件列出所有運行時的已知/可用實現。

您也可以使用屬性方法來構建一個用戶界面，讓用戶選擇他們想要的;我將它用於構建的開源Web應用程序框架：http://www.morphological.geek.nz/Morphfolia/Capabilities/AttributeDriven.aspx

來源

2010-06-21 23:39:51

使用OLAP後端？ DI可能是插件的一種合乎邏輯的方式，但我還沒有看到具有良好性能特點的插件。 – jro 2010-06-22 19:45:21

我沒有做過很多DW工作，但我認爲你需要知道你想問的問題，因爲這會影響它的設計;在這種情況下，我不希望人們能夠砍伐和改變algorythmns。就性能而言，我不是DI方面的專家，但我會認爲性能會是合理的 - 取決於您的方法。就你而言，如果你追求特定的性能要求和靈活性，你可能會發現你的綠色「設計模式」牧場。 – 2010-06-22 23:51:11

我們已經在服務器和客戶端內部使用DI（Unity）。每個插件應該至少有兩個程序集：一個用於服務器端，將被加載到主數據被保存的同一個appdomain中（以避免編組），另一個在客戶端（Silverlight）上加載以公開附加功能給用戶。這兩個程序集都可以自動發現，並且如果存在於Plugins文件夾中，則可以加載它們。我們只是不知道如何在web服務中自動公開插件的服務器/客戶端程序集的新功能。 – 2010-06-24 10:04:32

Web服務的可擴展性框架/模式/良好實踐？

回答

相關問題