[review] MVP

之前在網路上搜尋MVP的時候，無意看到有人說MVC更適合web application這種stateless的開發，非常違反我直覺地描述，最近終於發現可能得出處，是一本書

Brownfield Application Development in .NET，中文翻譯:軟體構築美學

先說違反直覺的部分，首先MVC提出非常早，遠早於現在流行的web application，也就是說MVC一開始是為了application設計才對，以這種觀點，application大多屬於有狀態的(state)，很少是stateless

作者有幾點小小的誤會，首先MVC架構定義跟傳統不大一樣，可以參考POSA一書對MVC架構的描述，MVP不是Martin Folwer提出來的，首先是由IBM於1997年左右提出的，Martin Folwer的MVP算是IBM的改良版本，這種誤解有點類似Martin Folwer提出了refactoring的概念是一樣的，不過Martin Folwer是一個總結並且發揚光大的人是肯定的，非原本名詞的提出者，一點都不損及Martin Folwer的地位

撇開這個不講，書中對各種模型的描述倒是很清楚，如Passive View、Supervising Controller、MVC、MVP

為了觀察web application，先考慮過去MVC是由誰驅動?大多是由應用程式建立了一堆view之後，再由view引發事件驅動controller，可是在web appliction，卻是由網頁直接接觸controller，然後再產生新的view(網頁)

因為stateless以及web流程的特性，controller變成了進入點，再加上route的概念盛行，controller工作變成了，如何引導流程，且非由view創立出來的，所以整體的角色改變了

再者MVC本身有個小小的缺點，view本身是認知model的存在(耦合性)，這有一點點暴露風險的部分是，程式設計師會直接透過view去操作model，而非controller，此外view往往為了model必須要修改，無法獨力發展

MVP有效的解決這問題，首先view直接獨立發展，畫面更新等等事情交由presenter去考慮，model本身從前就已經很獨立了，現在更加地不用透過類似observer patter去通知view，耦合更少。在view與model都獨立的狀況下，必須有角色負責媒合兩者，那個就是presenter，而presenter必須利用IoC的概念，引入兩者view跟model(有可能有很多view與很多model instances)，作為媒介

可是這時候，一些事件的傳遞要如何作用?在web application上面，這件事情不是很嚴重，因為server直接扮演了controller以及route腳色，如同第一個MVC圖片一樣，只是現在將MVC中的MV改成了MVP，但是在應用程式上呢?所以才有上面的application controller存在。

這裡可能會冒出的疑問是，那麼model跟view之間的耦合性不見了，那麼如何更新view?由presenter，但是presenter也無法知道model有沒有更新阿!?Martin Folwer告訴我們，如果要達到主動更新只好把類似observer pattern再放到model跟presenter身上，耦合性又回來了XD天下沒有白吃的午餐，不過透過MVP，讓view與model可以獨立發展，大大提高view的resue了