MVC是一個不錯的設計方式,可以把商業邏輯、呈現與流程控制分開來處理,各司其職,讓程式更好維護。所以考慮在目前的程式中,加入MVC的支援。
Front Controller
傳統的網頁伺服器程式,主要還是透過網頁伺服器來驅動,有一些動作其實在伺服器端已經完成了。以php為例,其實每一個當作應用程式進入點的php,都可以視為一個Controller,但是這樣會讓應用程式的組織變得很複雜。所以許多framework例如CakePHP、CI、Symphony等等,幾乎都是使用Front Controller,實際上處理所有網址的都是一個index.php,背後透過網址轉換機制(例如apache httpd的rewrite)來把各個模組的網址對應到這個index.php。這樣做可以讓許多事情可以集中控管與出裡,程式變得更簡單,也不用在不同的進入點撰寫其實是重複的程式碼。在front controller中,程式會分析收到的url資訊,來決定要載入的模組的controller程式,並且提供相關的view與model資源。
為什麼會提到Front Controller呢?node.js跟php、asp等伺服器端程式有一個重要的差異,就是他本身就是伺服器,而不是附屬在伺服器裡面的一個程式執行環境。所以...之前實作好的router與dispatch機制,實際上已經差不多涵蓋了Front Controller的主要功能,而且不這樣做的話,也很難讓伺服器使用者開發自己的程式。
所以接下來的重點,會擺在View與Model這兩個部分。View的部份可能會著墨比較深,Model部分我還在考慮要怎麼設計...做出ORM並不是我的目的,而且會花太多時間。對於View來說,從Model取得資料,並且在設計好的template呈現比較會是重點。所以可能可以設計一個系統,經由Controller讓使用者媒合View與Model,並且透過事件驅動讀取資料到呈現的過程(非同步)。
方向
可以選擇的設計方式大概有:
不過還是從實際著手設計與測試時,再來決定怎麼做。
請問一下可以有實作過 nodejs 互相連線的問題嗎, 就是兩台不同主機nodejs伺服器(load balance),
可以說明詳細一點嗎?提供的是怎樣的伺服器?(http, https, websocket, tcp etc.)
如果是需要load balance,https://github.com/nodejitsu/node-http-proxy可以很簡單地做到反向代理,不過只支援http, https以及websocket。不過使用nginx效能可能比node-proxy好,只是需要比較複雜的設定。
如果需要的是兩台伺服器互相溝通,也許可以考慮幾種方式:
當然,你也可以設計好資料格式,然後透過基本的tcp伺服器來溝通。
我看過有些討論 認為Node 並不適合拿來實作傳統Web MVC 架構
http://www.linkedin.com/groups/NodeJS-Application-in-MVCstyle-3769732.S.79191685
不知道fillano 大大有什麼看法呢
我覺得Erhan的分析很好。另外提供一篇做參考:http://blog.targeterapp.com/post/22984987832/why-we-moved-from-nodejs-to-ror
關鍵還是看你要怎麼用...目前有的framework太輕量,對於比較複雜的website開發會有一些困難。基本上需要等到有這類較成熟的framework出現。
當然,會Javascript的人很多,但是真正熟悉的人不多。但是對於開發node.js來說,需要對於Javascript有足夠的認識,才能應付自如。對於團隊開發來說,要集合這樣的人也不太容易...這是另一個問題。
另外,對於大型的MVC開發,需要讓三者完全分離(各自為獨立的檔案/程式等),才容易協同開發。另外,model是一大問題...要做抽象化來跨資料庫,要有彈性與工具來做資料庫遷移等等,目前可能還沒有夠完整的方案。controller跟view還沒那麼複雜。