您在這裡

Drupal到底是不是MVC?你需要MVC嗎?

jimmy's 的頭像
jimmy 在 2007-07-16 (週一) 02:18 發表

PHP is the most popular language for creating Content Management Systems and some of the CMSs implement MVC. The popular Drupal CMS is an example of optional MVC. The core system separates the data, processes, and presentation but still lets users create shortcuts to the data when developing new features. Optional MVC provides the advantages of MVC while allowing developers to plug in external modules that are not yet MVC.
reference from http://en.wikipedia.org/wiki/Model-view-controller

曾經有人問我Drupal是不是MVC,上次又聽到有人說Drupal不是MVC,又有人批評Drupal要達到MVC很難...

要討論此話題前,先瞭解MVC只是一個架構,並不表示需要語言完全的follow定義限制好這個架構,當然亦可以有程式完全依照架構實現所有的規則,這可以稱作完全的MVC應用程式,ROR framework便是一個很好的例子,依照他的framework下去開發,絕對是MVC。

至於Drupal呢,在核心中將View、Model和Control都分開處理了,提供了大量function來分層使用,但並沒有在物件上就將MVC架構定義死,也就是說若要開發Drupal內的模組,「不一定」需要follow MVC架構,但drupal的核心開發者思維上皆是依照MVC的架構來處理了。這也造就了Drupal為什麼如此有彈性的原因。

具體一點說明呢,hook system就是Drupal保持彈性的好例子。看看hook_nodeapi這個function好了。如果說他就是一個MVC架構也不為過:
model有insert、update、delete,control有load、search result、validate,view有prepare、print、view、rss item等等。
但是在drupal裡頭,若我爽想在view裡頭做做control的事情行不行?當然可以!但這就違反了MVC架構的原則和切割...不過有些時候呢就必須要這樣做,原則和架構只是拿來做參考和指引用的。

什麼時候會想幹這種勾當呢,譬如說我想要在一個使用者瀏覽一篇node時,也就是invoke到nodeapi的view的時候,為使用者加上他已經讀取了這篇文章的紀錄(update model,control做的事情),然後將文章顯示為新的未讀取文章,若查到這篇文章是已經讀取過了,便不需要做update的動作,直接顯示已讀取。
仔細來看這樣的流程,就可以知道實際上的確可以做到control和view分離,但是要分離得這樣做:

control:SELECT看是否已經讀取,沒有的就執行UPDATE
view:再SELECT一次,查看文章是否已經讀過,並產生view加上是否已經閱讀過的「新文章」標示
加起來一共三次資料庫的存取。

但是若全部都綁在nodeapi裡頭的view中做呢,就只要

SELECT看是否已經讀取,沒有的就執行UPDATE,將SELECT到的資料轉換成「新文章」標示
一共兩次的資料庫存取

當然這個例子可能不夠好,因為實際上drupal的運作大多把control處理好的資料暫存起來在記憶體裡($node object),再透過物件傳給view的時候來做。但這只是一個簡單的例子,說明雖然Drupal提供MVC架構,但MVC架構並不是一個全然無需要改變的準則,所有動作都依據架構來做,會老得重複繞著圈子做一樣的事情。因此應用程式的API沒有限制死,雖然在架構上並沒有嚴謹,有時無法保證共同開發者的品質,但提供了更重要的彈性,有些簡單到不能再簡單的模組,就沒有必要follow MVC,跟自己的時間過不去了。

我想對Drupal而言,MVC重要的是在思維裡,寫一個模組可以爽就照MVC,不爽自己來,許多模組中可以看到厲害一點的程式設計者function本身的定義就會有MVC的架構了,不需要API裡頭太多的限制。架構有好就有壞,以MVC當作至高無上的準則評斷這個應用程式的好壞,大多沒有深入瞭解,甚至可能只是對架構的盲目而已。

p.s. 才剛剛發表完,又看到這篇討論串,講的真是太好了
http://drupal.org/node/116677

Themes share the V and continue to work when the M changes. Themes can optionally connect into the M and C but if they do, they have to be updated to match changes to core M and C.

Drupal's modular structure, with code out in the modules, could be equated to changing cars from their current 12 volts to the 24 volts used in trucks. You could make the change to the core car without changing any of the plug in options so long as the plug in options do not use the car's electricity. Your optional rear spoiler would continue to work. Your sound system with the 3000 watt woofer would be fried by the 24 volts.
http://drupal.org/node/116677#comment-206654

很好的譬喻啊,的確這常常在發生。因為MVC定義中將View給分離的太開,V太依賴C,若M一改變,V和C的重複使用性就變差。但在drupal裡頭常常看到的是,C常常得被各種模組重複利用,如node_teaser(),V也更廣泛使用在第三方的module,如theme('node_list',$array); => theme_node_list();,但M也就是node的資料處理層,已經不知道升級了多少版本了,依賴他的其他的module都還可以存活的下去。

--
from open mind to open source~

其他Drupal v.s./ as MVC的文章
http://archivemati.ca/2006/01/21/drupal-as-a-mvc-framework/
http://www.gerd-riesselmann.net/archives/2006/01/drupal-as-mvc-framework

Swiss army knife: That's to the point, couldn't agree more :-). However, he concludes that Drupal is not a true MVC framework, but that developing is promising.

其實,MVC某種程度來說,是另一種商業塑造出來的思維吧。

--
from open mind to open source~

其實,MVC某種程度來說,是另一種商業塑造出來的思維吧。

深有同感,本來就不該為了 MVC而MVC
若是堅持 pure MVC,結果往往不一定比因地制宜的彈性 MVC好
像是 RoR 人家也沒有V一定不能兼差C,還是要看情況彈性點比腳好~~