模型 - >觀察者 - >查看 - >控制器 - >模型 - >

Question

我在閱讀設計模式，雖然作者同意觀察者模式很酷，但在設計時，每個人都會談論MVC。

我有點困惑，MVC圖不是循環的，是不是很自然的代碼流有封閉的拓撲？爲什麼沒有人說這種模式：

model -> observer -> view -> listener -> model -> .. 

如果視圖需要控制器，那麼模型需要觀察者，否？隨着Object.observe（）與下一個JavaScript版本一起出現，這種模式有什麼問題？

Answer 1

視圖和和控制器都是，也是觀察者。

視圖/是/觀察者，模型上的事件。控制器/是/視圖中事件的觀察者。控制器在模型中觸發命令，導致它改變傳播由視圖觀察到的事件，從而適當地改變其狀態。

這個試圖解決的問題是讓UI響應模型中的變化，讓模型通過UI響應來自用戶的輸入。除了人類視覺脆弱以外，沒有什麼重要原因可以讓第三部分涉及到這一點 - 設計一個命令和控制系統比事件驅動系統要容易得多，但令人驚訝的是後者通常更容易實現。

您提出的設計的一個問題是關注點的分離。使用MVC（正確完成時，使用消息/事件），每個組件只知道自己和自己的問題。通過你提出的模型，Observer組件必須知道如何編排視圖，視圖更適合自己完成。

當然，你認爲控制器協調模型的變化，爲什麼我們不能在關係的遠端有一個等效的組件？實際上，雖然我們通常在'控制器'空間中實現某些東西，但是通常只是'基礎設施'將消息/事件/命令從視圖傳遞到模型，模型會相應地進行響應 - 也就是說，控制器轉變成一個簡單的路由器。由於我們更好地理解DDD和聚合根模式，以及事件採購的可能性，現代設計中對編排組件的需求已經減少。

最後，您提到的模式最初是由四人幫記錄的，因爲它存在於實踐中，並且相對普遍。當時沒有移動或web應用程序，他們認爲是最大的系統之一是gimp。隨着我們的技術已經成熟，我們的應用程序通過多種渠道交付，因此在這個領域有發展模式。幾年前，我們正在討論MVC2，然後我們轉向MVVC和MMVC這些古怪事物。現在，隨着CQRS，事件採購和DDD的出現，我們開始討論MV，因爲編排方法已經開始顯示其侷限性，並且事件驅動型系統脫穎而出。