交互服務與交互請求對象

Question

我想知道什麼時候使用Prism，交互請求對象比使用交互服務模式更可取。 對於我來說，交互服務應該用在簡單的情況下，即當你有一個標準的消息彈出窗口，只有文本內容將被改變。另一方面，當UI更復雜時，交互請求對象更合適。但交互服務更容易實現，並且需要更少的代碼。 你覺得呢？

Answer 1

我同意你說的交互服務可以適用於普通的交互行爲，如消息框等

在我看來，把它歸結爲階級的責任。換句話說，你是希望ViewModel還是View負責指定應該發生什麼類型的交互？

考慮一個基本的交互服務接口：

public interface IInteractionService{ 
    MessageBoxResult ShowMessageBox(string messageBoxText, string caption, MessageBoxButton button); 
} 

這是一個從觀察什麼樣的行爲ShowMessageBox的類型會產生界面相當明顯。這就給ViewModel一定程度的控制，以指定它期望發生什麼類型的交互行爲。這種方法的問題是你的ViewModel現在依賴於IInteractionService，並且明確了它的交互行爲期望。這可能會讓ViewModel的可重用性降低。

利用交互對象，您可以將更多交互行爲的責任放在視圖上。換句話說，您可以更改交互的行爲和外觀，而不會直接影響ViewModel。例如，交互請求的V1可以顯示一個簡單的MessageBox。交互請求的V2可能是一個更復雜的對話框，需要更多的用戶交互，只需點擊一下按鈕即可。這種交互行爲的改變可以在不需要修改ViewModel的情況下進行管理。如果您有一位正在從事項目工作的UI設計人員想要選擇更換或更改與交互請求綁定的視圖的行爲或外觀，這會非常有用。

如果您願意，您可以使用兩種策略。換句話說，一個用於常見交互行爲的交互服務和用於更復雜行爲的交互對象。

總之，交互服務可以更容易使用，但交互對象可以使您的ViewModel更加可重用，在我看來。

Answer 2

使用交互服務顯示消息框的巨大缺陷是父窗口 - 或者說缺少一個窗口。

您應該從視圖模型或服務實現中提供哪個窗口作爲消息框的父級？如果您選擇Application.Mainwindow，那麼您對整個應用程序佈局做出了巨大的假設。

知道過程中唯一的實體如何來顯示交互是視圖。無論是使用消息框還是使用頁內疊加層。

如果使用交互服務，有幾個有效參數可以支持。常用的是它更容易。這可能是事實，但對於許多其他不應該完成的事情也是如此，例如後面的代碼等。