奧東......about MVC

引入

http://kb.cnblogs.com/page/502983/

主流MVC框架向command轉型是有緣由的，除了command自身的優點以外，一個很是重要的緣由就是：因爲缺乏合理的組織依據，controller的粒度很難拿捏

controller不一樣於view與model，view與model都有各自自然的粒度組織依據，view的組織粒度直接承襲用戶界面設計，model的組織粒度則是依據某種分析設計思想（如OOA/D）進行領域建模的結果，controller須要同時協調view與model，可是view與model的組織結構和粒度都是不對等的，這就使得controller面臨一個「在多大視圖範圍內溝通與協調多少領域對象」的問題，因爲找不出合理的組織依據，設計者在設計controller時每每感到無所適從。相比之下，command則徹底沒有controller的困惑，由於command有一個自然的組織依據，這就是user action。

針對一個user action設計一個command，而後將二者映射在一塊兒，是一件很是天然而簡單的事情。不過，須要說明的是這並不意味着全部command的粒度是同樣的，由於不一樣的user action所表明的業務量是不一樣的，所以也決定了command是有「大」有「小」的。遵循良好的設計原則，對某些較「大」的command進行分解，從中抽離出一些可複用的部分封裝成一些較「小」的command是值得推薦的。不少MVC框架就定義了一些相關的接口和抽象類用於支持基於組合模式的命令拼裝。

不變的地方：

無論是基於controller仍是基於command，MVC架構中界定的「協調view與model交互」的控制器職責是不會變的，都須要相應的組件和機制去承載與實現。在基於command的架構裏，command承擔了過去controller的部分職責，從某種意義上說command是一種細粒度的controller，可是command的特性是偏「被動」的。一方面，它對於view和model的控制力比controller弱化了不少， 好比，通常狀況下command是不會直接操縱view的。另外一方面，它不知道本身與什麼樣的user action映射在了一塊兒，也不知道本身會在何種狀況下被觸發執行。支撐command的運行須要額外的註冊、綁定和觸發機制，是這些機制加上command一塊兒實現了controller的職責。因爲如今多數基於command的MVC框架都實現並封裝了這些重要的機制，因此從某種意義上說，是這些框架自身扮演了controller角色。