2016-10-07 36 views
0

我正在寫一個小應用程序來控制一些實驗室設備(溫度控制室,電源和電壓表)。使用WPF,C#和MVVM。想知道將設備的更新傳回ViewModel和View的模式是什麼。我爲每件設備建立了一個模型類,它揭示了設置電源電壓,打開烤箱,讀取電錶測量值等特性和方法。我想知道最佳模式以通知電源模式(從電壓限制模式切換到電流限制模式)和當前腔室溫度等屬性變化。我有兩種不同的情況:在C#MVVM中控制/監視外部設備的結構?

1)溫度室:室內測得的溫度自行緩慢移動,我需要每秒鐘監測並顯示當前讀數。 2)電源:電源通常處於電壓限制模式(保持電壓恆定並讓電流根據需要變化),但是如果電流達到上限,每隔幾小時它將模式切換爲電流限制模式(不要讓電流超過1安培,並根據需要讓電壓開始下降)。這完全由電源控制,但是當它發生時,我需要知道這種模式切換。

我可以看到ethier在模型中建立一個線程來輪詢設備並在溫度變化或模式改變時引發事件。還可以看到保持模型簡單並將輪詢放入ViewModel中。通信開銷微不足道,所以想知道是否有這種情況的建議。

謝謝你,布萊恩

+3

[最佳實踐殭屍](http://meta.stackexchange.com/a/142354/1228) – Will

回答

0

我會考慮通過實現一個接口的服務類暴露的硬件數據。服務類可以根據需要輪詢硬件並引發事件。

該接口將允許您爲單元測試應用程序創建一個模擬實現,而無需連接到物理硬件。

應用程序的視圖模型應該在其構造函數中使用服務類的實例,掛鉤所有事件,並在準備關閉時解除掛鉤。

我不會把輪詢直接放在模型或視圖模型中,因爲它處理特定的硬件實現。如果可以儘可能多地將其抽象出來,那麼測試就更容易了。

+0

我喜歡測試和隔離接口的想法。這聽起來像你的服務類本質上是一個不同名稱的模型 - 這不是一個真正的問題。如果我理解了,你將創建一個服務類來監控硬件,並且存在控制硬件的模型類(即設置腔溫度,啓用/禁用溫度控制等)。從界面分離,什麼是把投票放在另一個班上的好處? –

+0

如果你打算實現服務類,你會希望模型和視圖模型儘可能簡單,除了是POCO之外沒有其他邏輯。服務類應包含應用程序中所需的所有邏輯。如果您不包含服務層,則將邏輯放入視圖模型中是有意義的。 –