也论PageController/FrontController与MVC
生活随笔
收集整理的這篇文章主要介紹了
也论PageController/FrontController与MVC
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
業界對于MVC這個名詞的誤解與濫用, 尤其是對與PageController和MVC的混淆, 在ASP.NET下, 比較典型的是出自于以下兩篇文章里面的遣詞造句:
http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesPageController.mspx?mfr=true
要從這兩篇文章上來看, 有時會產生錯誤的結論, 似乎PageController是MVC. 實際上MSDN上早期有一篇文章, 介紹如何移植其它系統的MVC到.NET, 那里頭說的是比較靠譜的. 其實狡猾的微軟作者在這兩篇文章中也并沒有確切的說PageController或FrontController是MVC. 比如看這幾句話:
"Front Controller。Front Controller 為所有頁面請求定義同一個控制器,因此能夠作出跨頁的導航決定。"
這句話對FrontController的說法與MVC所具有的特征牛頭不對馬嘴. FrontController僅是控制器實現的一種模式,存在著很多情況應用了FrontController而沒有應用MVC, 所以除了都有控制器之外不具有MVC的其它特征. 而且在這篇文章中所指的FrontController, "用于協調向 Web 應用程序發出的所有請求。此解決方案描述了使用單一控制器", 也和MVC的結構中Controller的作用是不符的. 單獨列出Front Controller和MVC進行名詞解釋, 已經把它們針對的問題進行了區分, 但在文章開頭卻存在著故意的誤導:
"您已經決定使用Model-View-Controller(MVC) 模式將動態 Web 應用程序的用戶界面邏輯與業務邏輯分隔開來。您已經考察了Page Controller 模式,但您的頁面控制器類具有復雜的邏輯,并且是較深的繼承層次結構的一部分,或者,您的應用程序是基于可配置的規則來動態確定頁面導航的。"
說實話這簡直是亂七八糟. Front Controller能夠解決頁面導航, 身份驗證等一系列問題, 其特點在于將通用的工作集中化, 這與MVC有什么關系? Front Controller模式要求關注Model嗎? 我將Model和View在一起實現, 肯定不是MVC了吧, 然后用Front Controller導航, 就不是Front Controller了? 還是我說我這種實現是一個變體? 就像下面這句話一樣?
"Model-View-Controller。Page Controller 是 MVC 控制器部分的實現變體。"
這句話通過所謂的"變體"二字, 硬生生把PageController與MVC扯上關系. PageController從本質上講, 絕非MVC, 因為視角和針對的問題完全不同. 如果單獨的考察每一個PageController, 實際上可以說是分布式的FrontController. 尤其是微軟的實現方式, aspx作為view是aspx.cs的子類, 而Page又是HttpHandler的實現, 而Model在這種模式下可以根本不予提及. 這就是說View和Controller實際上是一個對象, 而Model到底如何實現, Model/View/Controller如何交互, 與PageController這種結構的特征毫無干系. PageController這個模式, 并不關注MVC所關注的問題, 它既不是MVC, 也絕不是MVC的一個子模式.
當然, 如果你Model以及Model與PageController的互動實現的妥當, 就變成了類似Document-View的模式, 微軟把這種模式也叫做MVC的"變體", 用以在模式愛好者中間吸引初學者推廣那臭名昭著的MFC. 這些說法純屬混水摸魚濫竽充數的伎倆, 大家必須小心謹慎的注意, 雖然MFC和ASPX在一些方面都很好用, 管它們的實現方式叫MVC也不損害自己的利益, 但是如果被這些說法混淆了對名詞的定義, 在你看純技術文章中出現這些名詞時, 可能會造成障礙; 而在寫文章時, 由于傳播了這些模棱兩可的概念, 就會給初學者帶來潛在的危害.
由于MVC作為一個時髦名詞(其實已經有20年以上的歷史了)最近廣泛的流行, 被大規模濫用, 而且似乎代表著良好的設計, 所以基本上什么東西都要和MVC掛上勾. 比如上面兩篇文章基本就是文字游戲, 可以說是微軟忽悠模式跟隨者的文章. 現在的普遍情況是, 只要能找出一個明確的Controller, 很多人就管這種方式叫MVC, 或MVC的一種"變體", 而根本不管Model和View的實現及特定的實現方式是否是該結構的實現所不可或缺的; 而MVC強調的就是Model/View/Controller之間的關系, 所以我個人認為不能把"能轉換成MVC的結構"與"MVC結構"隨便等同: 一個名詞的定義涵蓋范圍越廣, 它到底指代什么就越不可靠.
實際上, Fowler在一篇文章中明確的說過, 現在Web上廣泛使用的方式, 叫做InputController更合適. 這點我也有所認同, 比如在RoR和php上的一些MVC的實現方式, 其實如果按照經典MVC的結構嚴格考察, 你說它不是完全完整的MVC也可以成立; 但是那些方式也確實接近于MVC擁有幾乎全部MVC的基本特征, 所以叫做MVC比起PageController和FrontController更順理成章. 完整的MVC -> 不完整的MVC, 不完整到一定地步, 就不能再叫做MVC了.
其實不是MVC, 不代表這種結構就不好不合理, 每一個模式都有自己如魚得水的范圍, 而不同模式的適用范圍往往又有所重疊; 正是這種非要和MVC攀親戚的做法, 反而使得PageController等模式在不知不覺間就矮了一頭. 在Fowler的POEAA中, FrontController/PageController和MVC是不同的三個模式, 上面兩篇MSDN文章在最后也給出了對POEAA的參考, 不可能不知道這種有廣泛基礎的劃分方式, 說實話這樣的文章比起糊涂人寫的文章應該遭到唾棄.
另外需要說明的是, FrontController與(PageController或MVC), 我個人認為并非是互斥的模式. 刨除PageController是FrontController的一種分散式的特殊形式所帶來的相似性之外, 實際上FrontController可以與PageController并存, 也可以與MVC并存, 作為更外圍的控制器存在, 處理一些共同的需求. 比如關于前兩天對于WebForm與MS MVC的討論, 就可以實現一個FrontController, 然后WebForm更合適的地方使用WebForm(PageController), 而MVC更合適的地方使用MVC, 由FrontController提供對外的統一與導航, 并處理驗證等通用任務.
個人感覺現在很多人包括一些不錯的開發者對MVC/MVP/MVPC等模式結構的誤解, 是由于沒有統一的描述方式所決定的, 包括Fowler對于腳本/表模塊/領域模型的割裂也是如此, 最近在構思一些能夠較好的說明這些結構模式的詳細描述的文章, 看看能不能這些問題一次說清楚, 給出一個共同的語言. 同時這種說明方式, 也能夠順便給ActiveRecord/Mapper等一系列話題明確的區分方式, 以及結合最近流行的Web應用給出一個初步指導, 判斷以下問題:
1. 何時使用MV(P/C/PC), 或其它更復雜/簡單的模式.
2. 何時使用表模塊, 表入口等方式, 何時使用領域模型.
3. 何時及如何同時使用表模塊等數據驅動方式與領域模型等更加面向對象的方式, 為什么它們是統一的而非Martin說的非此即彼.
4. 圍繞這些話題展開的其它話題.
5. 給出你的做法的不合理性, 告訴你何時應該改變, 如何改變.
6. 給出你的做法的合理性, 你再也不需要為"我的做法不夠面向對象"/"我的做法不是MVC"等是否高級的問題而苦惱.
很多人認為我的文章太長, 我保證我這些內容, 要比Martin的企業架構應用模式短的多, 精煉的多, 且絕對說的比他清楚. 作為一個我所定義的"入門者", 不是說我比Martin這樣的人在這些方面有更深刻的認識; 但是作為在海邊撿貝殼的孩子, 我感覺確實撿到一個更漂亮的貝殼, 可以更清楚的在一些問題的局部, 把故事講的更清楚. 當然, 你要是認為一個中國人/一個普通開發者/一個身邊的網友, 不可能揀到這樣的貝殼, 你還是看那些商業文章更保險, 那我也無話可說, 我只是希望能夠分享一下, 不要臉點說也趁機炫耀一下~
同時我最近正在自己正在使用這種描述方式進行實踐指導, 還需要一些時間驗證和修正, 有興趣的朋友請耐心等待 :) .為了驗證這種描述方式的可行性, 同時讓Martin這些大牛/大嘴也可以參閱并改進一下, 我個人打算拿寫成比較嚴謹的風格并翻譯成英文, 不過我英文寫作能力很差, 不知道是不是有人愿意合作呢? 另外這些內容也可擴展成書, 不過我完全沒有出書的經驗也沒有時間去當一個合格的技術宣傳者, 這方面要是誰愿意代勞, 也可以合作.
http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesPageController.mspx?mfr=true
http://www.microsoft.com/china/MSDN/library/architecture/patterns/esp/DesFrontController.mspx?mfr=true
要從這兩篇文章上來看, 有時會產生錯誤的結論, 似乎PageController是MVC. 實際上MSDN上早期有一篇文章, 介紹如何移植其它系統的MVC到.NET, 那里頭說的是比較靠譜的. 其實狡猾的微軟作者在這兩篇文章中也并沒有確切的說PageController或FrontController是MVC. 比如看這幾句話:"Front Controller。Front Controller 為所有頁面請求定義同一個控制器,因此能夠作出跨頁的導航決定。"
這句話對FrontController的說法與MVC所具有的特征牛頭不對馬嘴. FrontController僅是控制器實現的一種模式,存在著很多情況應用了FrontController而沒有應用MVC, 所以除了都有控制器之外不具有MVC的其它特征. 而且在這篇文章中所指的FrontController, "用于協調向 Web 應用程序發出的所有請求。此解決方案描述了使用單一控制器", 也和MVC的結構中Controller的作用是不符的. 單獨列出Front Controller和MVC進行名詞解釋, 已經把它們針對的問題進行了區分, 但在文章開頭卻存在著故意的誤導:
"您已經決定使用Model-View-Controller(MVC) 模式將動態 Web 應用程序的用戶界面邏輯與業務邏輯分隔開來。您已經考察了Page Controller 模式,但您的頁面控制器類具有復雜的邏輯,并且是較深的繼承層次結構的一部分,或者,您的應用程序是基于可配置的規則來動態確定頁面導航的。"
說實話這簡直是亂七八糟. Front Controller能夠解決頁面導航, 身份驗證等一系列問題, 其特點在于將通用的工作集中化, 這與MVC有什么關系? Front Controller模式要求關注Model嗎? 我將Model和View在一起實現, 肯定不是MVC了吧, 然后用Front Controller導航, 就不是Front Controller了? 還是我說我這種實現是一個變體? 就像下面這句話一樣?
"Model-View-Controller。Page Controller 是 MVC 控制器部分的實現變體。"
這句話通過所謂的"變體"二字, 硬生生把PageController與MVC扯上關系. PageController從本質上講, 絕非MVC, 因為視角和針對的問題完全不同. 如果單獨的考察每一個PageController, 實際上可以說是分布式的FrontController. 尤其是微軟的實現方式, aspx作為view是aspx.cs的子類, 而Page又是HttpHandler的實現, 而Model在這種模式下可以根本不予提及. 這就是說View和Controller實際上是一個對象, 而Model到底如何實現, Model/View/Controller如何交互, 與PageController這種結構的特征毫無干系. PageController這個模式, 并不關注MVC所關注的問題, 它既不是MVC, 也絕不是MVC的一個子模式.
當然, 如果你Model以及Model與PageController的互動實現的妥當, 就變成了類似Document-View的模式, 微軟把這種模式也叫做MVC的"變體", 用以在模式愛好者中間吸引初學者推廣那臭名昭著的MFC. 這些說法純屬混水摸魚濫竽充數的伎倆, 大家必須小心謹慎的注意, 雖然MFC和ASPX在一些方面都很好用, 管它們的實現方式叫MVC也不損害自己的利益, 但是如果被這些說法混淆了對名詞的定義, 在你看純技術文章中出現這些名詞時, 可能會造成障礙; 而在寫文章時, 由于傳播了這些模棱兩可的概念, 就會給初學者帶來潛在的危害.
由于MVC作為一個時髦名詞(其實已經有20年以上的歷史了)最近廣泛的流行, 被大規模濫用, 而且似乎代表著良好的設計, 所以基本上什么東西都要和MVC掛上勾. 比如上面兩篇文章基本就是文字游戲, 可以說是微軟忽悠模式跟隨者的文章. 現在的普遍情況是, 只要能找出一個明確的Controller, 很多人就管這種方式叫MVC, 或MVC的一種"變體", 而根本不管Model和View的實現及特定的實現方式是否是該結構的實現所不可或缺的; 而MVC強調的就是Model/View/Controller之間的關系, 所以我個人認為不能把"能轉換成MVC的結構"與"MVC結構"隨便等同: 一個名詞的定義涵蓋范圍越廣, 它到底指代什么就越不可靠.
實際上, Fowler在一篇文章中明確的說過, 現在Web上廣泛使用的方式, 叫做InputController更合適. 這點我也有所認同, 比如在RoR和php上的一些MVC的實現方式, 其實如果按照經典MVC的結構嚴格考察, 你說它不是完全完整的MVC也可以成立; 但是那些方式也確實接近于MVC擁有幾乎全部MVC的基本特征, 所以叫做MVC比起PageController和FrontController更順理成章. 完整的MVC -> 不完整的MVC, 不完整到一定地步, 就不能再叫做MVC了.
其實不是MVC, 不代表這種結構就不好不合理, 每一個模式都有自己如魚得水的范圍, 而不同模式的適用范圍往往又有所重疊; 正是這種非要和MVC攀親戚的做法, 反而使得PageController等模式在不知不覺間就矮了一頭. 在Fowler的POEAA中, FrontController/PageController和MVC是不同的三個模式, 上面兩篇MSDN文章在最后也給出了對POEAA的參考, 不可能不知道這種有廣泛基礎的劃分方式, 說實話這樣的文章比起糊涂人寫的文章應該遭到唾棄.
另外需要說明的是, FrontController與(PageController或MVC), 我個人認為并非是互斥的模式. 刨除PageController是FrontController的一種分散式的特殊形式所帶來的相似性之外, 實際上FrontController可以與PageController并存, 也可以與MVC并存, 作為更外圍的控制器存在, 處理一些共同的需求. 比如關于前兩天對于WebForm與MS MVC的討論, 就可以實現一個FrontController, 然后WebForm更合適的地方使用WebForm(PageController), 而MVC更合適的地方使用MVC, 由FrontController提供對外的統一與導航, 并處理驗證等通用任務.
個人感覺現在很多人包括一些不錯的開發者對MVC/MVP/MVPC等模式結構的誤解, 是由于沒有統一的描述方式所決定的, 包括Fowler對于腳本/表模塊/領域模型的割裂也是如此, 最近在構思一些能夠較好的說明這些結構模式的詳細描述的文章, 看看能不能這些問題一次說清楚, 給出一個共同的語言. 同時這種說明方式, 也能夠順便給ActiveRecord/Mapper等一系列話題明確的區分方式, 以及結合最近流行的Web應用給出一個初步指導, 判斷以下問題:
1. 何時使用MV(P/C/PC), 或其它更復雜/簡單的模式.
2. 何時使用表模塊, 表入口等方式, 何時使用領域模型.
3. 何時及如何同時使用表模塊等數據驅動方式與領域模型等更加面向對象的方式, 為什么它們是統一的而非Martin說的非此即彼.
4. 圍繞這些話題展開的其它話題.
5. 給出你的做法的不合理性, 告訴你何時應該改變, 如何改變.
6. 給出你的做法的合理性, 你再也不需要為"我的做法不夠面向對象"/"我的做法不是MVC"等是否高級的問題而苦惱.
很多人認為我的文章太長, 我保證我這些內容, 要比Martin的企業架構應用模式短的多, 精煉的多, 且絕對說的比他清楚. 作為一個我所定義的"入門者", 不是說我比Martin這樣的人在這些方面有更深刻的認識; 但是作為在海邊撿貝殼的孩子, 我感覺確實撿到一個更漂亮的貝殼, 可以更清楚的在一些問題的局部, 把故事講的更清楚. 當然, 你要是認為一個中國人/一個普通開發者/一個身邊的網友, 不可能揀到這樣的貝殼, 你還是看那些商業文章更保險, 那我也無話可說, 我只是希望能夠分享一下, 不要臉點說也趁機炫耀一下~
同時我最近正在自己正在使用這種描述方式進行實踐指導, 還需要一些時間驗證和修正, 有興趣的朋友請耐心等待 :) .為了驗證這種描述方式的可行性, 同時讓Martin這些大牛/大嘴也可以參閱并改進一下, 我個人打算拿寫成比較嚴謹的風格并翻譯成英文, 不過我英文寫作能力很差, 不知道是不是有人愿意合作呢? 另外這些內容也可擴展成書, 不過我完全沒有出書的經驗也沒有時間去當一個合格的技術宣傳者, 這方面要是誰愿意代勞, 也可以合作.
轉載于:https://www.cnblogs.com/guaiguai/archive/2007/10/15/924215.html
總結
以上是生活随笔為你收集整理的也论PageController/FrontController与MVC的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 委托解释
- 下一篇: 对MIME格式的邮件文件进行解码获取其可