轉載自 http://www.jaceju.net/resources/webmvc/
透視 WebMVC
Jace Ju 2007/03/16
前言
以往我所開發的 Web 專案,大部份都是把核心放在操作 HTML ;就算後來使用了 Smarty ,卻還是迷失在視覺為重的設計觀點裡,使得後續開發與維護都變得非常麻煩。後來我自己歸納出問題發生的原因,絕大部份在於我接觸的專案常常是「畫面先行」。
「畫面先行」是由視覺設計人員來主導專案的架構,而這個架構則通常是因應客戶在網站流程上的要求而建立的;這也使得我在開發程式時就必須地採用他們決定好的頁面來套用程式,最後的結果就是導致重複的業務邏輯遍布在整個專案裡。
不過就算使用了 Smarty ,這種問題也還是沒有得到更進一步的解決。原因就在於我只是把 PHP 程式和 HTML 頁面拆開,而實際上同樣的業務邏輯卻沒有能夠包裝起來重複使用。直到我接觸了物件導向的觀念後,我才驚覺這種設計真的是不堪一擊。
於是我很認真地使用物件導向來封裝我的業務邏輯,並天真地以為讓它們能夠 reuse 後,程式的複雜度就會降低;但是逐漸地我發現到,我花在修改這些物件的時間竟然變得比以前長,我必須不斷地為它加入不同的判斷條件,好讓它應付所有可能發生的變化。可是這不是我所希望發生的結果呀!到底為什麼會變成這樣呢?
我發現很多時候我讓物件在發生錯誤時,自行丟出一個訊息給瀏覽器,或是透過 Smarty 將這些訊息包裝成畫面。但是過了幾個月之後的改版,這個物件的重用性變得越來越差,而且也變得越來越大。另外它跟 Smarty 的耦合性也太高,畢竟有時候我根本不想在這個時候使用 Smarty 丟出畫面,而是想讓上一層程式自己去決定!
後來我歸納出這一切問題的原因,都是我錯把 Smarty 當成主角 - 也就是網站架構的核心!
剛接觸 Smarty 時,我同時也耳聞了 MVC 這個設計模式。不過那時剛剛接觸物件導向,也還不瞭解什麼是設計模式;只知道使用 Smarty 的前輩們倡導大型的應用項目都應該朝向 MVC 的架構去設計。雖然我那時仍不清楚 MVC 的核心概念,然而這個開發方式卻帶給我一個很大的思考空間:為什麼要把一個應用程式分成三個部份?而在 Web 上這種開發方式也行得通嗎?在參考過一些書籍,這些問題仍似有若無的存在我的心中,所以我的程式架構依然沒有什麼改進。
直到在寫「 PHP Smarty 樣版引擎」這本書時,我也剛好讀到了「深入淺出設計模式」這本好書;而該書對 MVC 模式的介紹,正好解開我長年以來的疑惑。
原來真正的 MVC 是將「資料處理邏輯」、「程式流程」與「資料呈現」三者分離,而 Smarty 只是扮演了「資料呈現」的角色而已!
不過懂是懂了,但要如何將這個概念融入 Web 開發中,這點讓我覺得很頭痛。雖然發現很早就有人把 MVC 帶進 PHP 裡了,只可惜用的人不多,文件也比較少。所以在我的書中的 MVC 架構用得非常簡陋,只能說是 WebMVC 的雛形而已。而這時 Ruby on Rails 剛好在網路界萌芽,號稱將 MVC 帶入了 Web 開發中;並且首開先例,用影片來示範一個 Blog 系統的誕生,所以我也不可免俗地去抓回來玩看看 (我想很多寫 Java 的人大概就是這點所吸引) 。可惜我一看到 Ruby 那個奇怪的語法,就覺得看不下去了,所以只是照本宣科地把範例作一作,最後不了了之 (後來想一想真是可惜) 。
直到又過了好一陣子,在 CakePHP 、 Code Igniter 等號稱 PHP 界的 Rails 開發框架出現後,我便興致勃勃地去下載回來研究。而參考了它們的範例後,這時我才猛然醒悟!原來 Web 上的 MVC 架構是長成這個樣子!後來為了專案需要,更把 LifeType 的程式碼追了一遍,這才發現 WebMVC 竟是如此彈性而富有變化!
由於深刻體認到物件導向所帶給我的衝擊,我不得不承認以往我所嚮往的開發方式仍然有很大的改進空間。所以我想就從架構的改進開始,讓自己重頭去認識新的 Web 開發方式。