网址：http://blog.shian.tw/mvc.html
介绍：
以往我所開發的 Web 專案，大部份都是把核心放在操作 HTML ；就算後來使用了 Smarty ，卻還是迷失在視覺為重的設計觀點裡，使得後續開發與維護都變得非常麻煩。後來我自己歸納出問題發生的原因，絕大部份在於我接觸的專案常常是「畫面先行」。
「畫面先行」是由視覺設計人員來主導專案的架構，而這個架構則通常是因應客戶在網站流程上的要求而建立的；這也使得我在開發程式時就必須地採用他們決定好的頁面來套用程式，最後的結果就是導致重複的業務邏輯遍布在整個專案裡。
不過就算使用了 Smarty ，這種問題也還是沒有得到更進一步的解決。原因就在於我只是把 PHP 程式和 HTML 頁面拆開，而實際上同樣的業務邏輯卻沒有能夠包裝起來重複使用。直到我接觸了物件導向的觀念後，我才驚覺這種設計真的是不堪一擊。
於是我很認真地使用物件導向來封裝我的業務邏輯，並天真地以為讓它們能夠 reuse 後，程式的複雜度就會降低；但是逐漸地我發現到，我花在修改這些物件的時間竟然變得比以前長，我必須不斷地為它加入不同的判斷條件，好讓它應付所有可能發生的變化。可是這不是我所希望發生的結果呀！到底為什麼會變成這樣呢？
我發現很多時候我讓物件在發生錯誤時，自行丟出一個訊息給瀏覽器，或是透過 Smarty 將這些訊息包裝成畫面。但是過了幾個月之後的改版，這個物件的重用性變得越來越差，而且也變得越來越大。另外它跟 Smarty 的耦合性也太高，畢竟有時候我根本不想在這個時候使用 Smarty 丟出畫面，而是想讓上一層程式自己去決定！
後來我歸納出這一切問題的原因，都是我錯把 Smarty 當成主角 - 也就是網站架構的核心！
剛接觸 Smarty 時，我同時也耳聞了 MVC 這個設計模式。不過那時剛剛接觸物件導向，也還不瞭解什麼是設計模式；只知道使用 Smarty 的前輩們倡導大型的應用項目都應該朝向 MVC 的架構去設計。雖然我那時仍不清楚 MVC 的核心概念，然而這個開發方式卻帶給我一個很大的思考空間：為什麼要把一個應用程式分成三個部份？而在 Web 上這種開發方式也行得通嗎？在參考過一些書籍，這些問題仍似有若無的存在我的心中，所以我的程式架構依然沒有什麼改進。