2017-04-12 70 views
0

我打算將PRISM庫用於在PC上運行的項目,該項目控制一臺或多臺儀器,並可視化和存儲設備的數據並讓用戶輸入一些控制數據。這些設備具有各種數字和模擬傳感器和參與者。他們可以是不同的類型和智力。大多數情況下,他們沒有「真實」的智能,所有的控制邏輯都在PC中。 這種'智能'需要不斷讀取設備中的數據。通信可以是各種類型的,如COM端口,TCP/IP套接字,HTTP到Web界面等。PRISM控制外部設備

我不確定什麼是最佳的解決方案,即'智能邏輯'。由於需要與設備進行連續的通信,因此需要將其與所有UI任務分開。它將需要某種後臺工作者或線程中的狀態機來構建更高級的流程邏輯。

問題:它應該是每個設備在PRISM中註冊的實例作爲服務並引用該後臺工作者嗎?還是應該創建後臺工作人員並將其鏈接到每個配置的樂器所需的ViewModel以處理其數據以顯示和編輯?還是有另一個最佳解決方案?

回答

0

我覺得這對不是具體的PRISM一個更通用的架構問題...

我已經做了其他MVVM框架類似的東西和我的解決方案是基於一個監聽器(我只有TCP套接字與儀器聯合)註冊爲服務。在你的應用程序中,你可以有多個隊列或一個隊列與多個生產者。

來自設備的所有消息都被插入到併發隊列中,並且每個ViewModel(每個設備一個)從該隊列中讀取。

從ViewModel到設備的通信直接發生,而不經過「輸出」隊列。

整個應用程序建立在await/async模式之上,以將UI從通信中分離出來。我能夠同時發送和接收來自多個設備的多個命令和通知,沒有任何問題。

但這又是一個非常廣泛的問題,我的答案很多,取決於你如何與服務交互。我的解決方案在複雜性和靈活性之間取得了平衡,但也有很多其他體系結構可用。

+0

thx爲您的答案,Antonello。我寧願不安裝Windows服務,也不想在PRISM中使用更多的共享服務。但是,是的,這個問題可以被看作是相當普遍的架構 – infero

+0

我建議的模式也可以與PRISM中的共享通信服務一起使用,只需使用後臺工作人員來實現。我更喜歡這種單一的偵聽器體系結構,因爲它可以在出現問題時調試通信問題。 –