Unity應用架構設計(2)——使用中介者模式解耦ViewModel之間通信

<a></a>

<b>閱讀目錄</b>

<a href="http://www.cnblogs.com/OceanEyes/p/using_message_aggregator_mediator_communication_between_viewmodels.html#_label0">耦合的産生</a>

<a href="http://www.cnblogs.com/OceanEyes/p/using_message_aggregator_mediator_communication_between_viewmodels.html#_label1">中介者模式的引入</a>

<a href="http://www.cnblogs.com/OceanEyes/p/using_message_aggregator_mediator_communication_between_viewmodels.html#_label2">解耦ViewModel與ViewModel</a>

<a href="http://www.cnblogs.com/OceanEyes/p/using_message_aggregator_mediator_communication_between_viewmodels.html#_label3">小結</a>

當你開發一個用戶端應用程式的時候，往往一個單頁會包含很多子子產品，在不同的平台下，這些子子產品又被叫成子View（視圖），或者子Component（元件）。越是複雜的頁面，被切割出來的子子產品就越多，子子產品越多，彼此之間需要同步的資料和狀态就越頻繁，即易産生耦合。那麼如何保證在複雜業務情況下，各個子子產品之間可以随意通信并保持弱耦合關系，這正是本文所讨論的。

試想一下，你有這樣一下需求，點選 View A中的按鈕，View B也需要做出相應的改變。

這不是很簡單嗎。腦海裡迅速出現兩種解決方案：

1.View A 主動通知View B做出更新，也就是View A依賴 View B

2.View B監聽View A的ColorChanged事件，主動拉取資料并更新，即ViewB 依賴View A

這兩種實作毫無疑問是沒問題的，至少從結果上來看是正确的。但試想一下，在一個複雜的用戶端單頁應用程式，這種緊耦合關系會導緻程式的複雜度陡然上升。每個View/ViewModel依賴其餘對象，而本身又被其他View/ViewModel強引用。這顯然不是好的實踐方式。

還記得我在上一篇文章的對于MVVM的描述嗎？

MVVM的核心思想就是解耦，View與ViewModel應該感受不到彼此的存在。ViewModel與ViewModel之間也應該感受不到彼此的存在。

那麼如何消除這種緊耦合關系呢？交給中介者設計模式來解決吧。

我們需要添加一個中介者，每個ViewModel Publisher對象都會在自己狀态改變時，告訴中介者。每個ViewModel Subscribers 都需要告訴中介者請求來時進行怎樣的響應。

在沒有中介者之前對象之間都需要彼此認識，互相引用，是一種強耦合關系。有了中介者之後，徹底解耦。

那麼現在就需要定義一個中介者，稱為MessageAggregator。因為由它來轉發消息，是以核心是一個字典，儲存了所有需要被轉發的消息。它的Key為消息的唯一Id，Value代表一個對該Message的處理程式。

通過中介者MessageAggregator對象，ViewModelB Subscribe一個對消息來時的處理函數：

ViewModel A在自己狀态改變時，Pulish狀态改變的消息給中介者：

中介者模式常常用來協調相關的GUI元件，可以讓對象之間傳遞的消息變得簡單。但如果設計不當，中介者本身會變得過于複雜。

本文轉自木宛城主部落格園部落格，原文連結：http://www.cnblogs.com/OceanEyes/p/using_message_aggregator_mediator_communication_between_viewmodels.html，如需轉載請自行聯系原作者