全 Javascript 的 Web 開發(fā)架構(gòu)：MEAN
引言
最近在Angular社區(qū)的原型開發(fā)者間，一種全Javascript的開發(fā)架構(gòu)MEAN正突然流行起來。其首字母分別代表的是：(M)ongoDB——NoSQL的文檔數(shù)據(jù)庫，使用JSON風(fēng)格來存儲數(shù)據(jù)，甚至也是使用JS來進(jìn)行sql查詢；(E)xpress——基于Node的Web開發(fā)框架；(A)agular——JS的前端開發(fā)框架，提供了聲明式的雙向數(shù)據(jù)綁定；(N)ode——基于V8的運(yùn)行時環(huán)境（JS語言開發(fā)），可以構(gòu)建快速響應(yīng)、可擴(kuò)展的網(wǎng)絡(luò)應(yīng)用。
MEAN架構(gòu)的示意圖
MEAN的支持者宣稱，如果整個開發(fā)棧均能使用JS，必然會大大地提高效率，這一點(diǎn)毋庸置疑是一個很大的賣點(diǎn)。這樣一來，開發(fā)人員（無論是前端還是后端）不僅能使用一致的數(shù)據(jù)模型，在其它方面也同樣可以獲得一致的編程體驗。
例如，拿Mongo來說，你可以使用類JSON格式（BSON，二進(jìn)制的JSON）來存儲數(shù)據(jù)，然后在Express/Node中調(diào)用JSON查詢語句，再將結(jié)果以JSON格式傳給前端的Angular顯示，這樣，也自然使調(diào)試程序容易了很多。
注意: 事實(shí)上，在MEAN架構(gòu)中，前端的Angular并不是必須的，你可以將它替換成其他的前端框架，如Backbone、Ember或者Polymer。
為何選擇MongoDB？
如上所提，這個架構(gòu)最重要的優(yōu)勢在于能使用單一語言，這也是其選擇了Mongo的首要原因。 這里就不討論noSQL的是與非了。一些人對MEAN架構(gòu)的指責(zé)在于，MongoDB可以很好地勝任中小型的應(yīng)用，但是對于大規(guī)模應(yīng)用（***用戶）來說可能就捉襟見肘。我想說的是，這完全取決于你如何使用它。
SQL數(shù)據(jù)庫本身是強(qiáng)類型的，因此可以在很大程度上保證某種層次的一致，從而確保許多類型的臟數(shù)據(jù)一開始就沒辦法進(jìn)入數(shù)據(jù)庫。而NoSQL則是弱類型的數(shù)據(jù)庫，這使得它在數(shù)據(jù)驗證方面力不從心，而只能交給開發(fā)人員來實(shí)現(xiàn)，基于這樣的特性，它尤其適合存儲那些不規(guī)范的數(shù)據(jù)，特別是在原型開發(fā)階段，此時數(shù)據(jù)模型正在經(jīng)歷快速變化。
SQL和noSQL間的技術(shù)差別，歸根結(jié)底是要在性能和穩(wěn)定性間作出平衡。有些情況下，對數(shù)據(jù)的事務(wù)處理一旦設(shè)定后就不會輕易變化，那么此時使用Mongo就非常合適；然而有時候也會涉及更為復(fù)雜的事務(wù)處理，會牽扯到許多獨(dú)立的業(yè)務(wù)邏輯，由于Mongo并沒有提供一個簡單的數(shù)據(jù)模型來支持一定級別的原子操作，因此SQL在這個時候可以派上用場。
但無論如何，不論你是否選擇MEAN中的M，你最終都需要根據(jù)自身的需求選擇出合適的工具來做正確的事情，
為何是Express?
可以簡單地把Express看成是一個在Node平臺下搭建Web應(yīng)用的工具集。在Node的基礎(chǔ)上，它提供了許多簡潔的接口來創(chuàng)建請求節(jié)點(diǎn)、處理cookie等，此外還提供了許多功能來幫助你搭建自己的服務(wù)器。總的來說，Express在以下幾個方面有優(yōu)勢：
-
設(shè)置REST路由簡單***：
app.get(/account/:id,function(req, res){/* req.params('id') is available */});
-
支持Jade或Mustache等模板引擎
-
自動HTTP頭處理:
app.get('/',function(req,res){ res.json({object:'foo'}); });
-
支持Connect中間件，可以插入額外請求或響應(yīng)處理，如用戶驗證
-
提供輔助函數(shù)解析POST請求
-
防范XSS
-
優(yōu)雅的錯誤處理
如何快速上手MEAN
如果想要很快上手MEAN，那么mean.io是一個很不錯的選擇。該項目旨在解決MEAN架構(gòu)中一些常見的集成問題, 目前維護(hù)得很好，文檔也很清楚，而且可以很方便地自行添加第三方庫，還能和Yeoman配合使用（通過 generator-mean by James Cryer）。
在進(jìn)一步閱讀前，先假定我們同意以下觀點(diǎn)：（a）Mongo至少非常適合于全Javascript堆棧的原型設(shè)計；（b） 承認(rèn)即使像Angular般如日中天，終有一天也會被其他的一些JS框架給取代，只要它們能幫助我們快速方便地將這個架構(gòu)快速搭建起來。
接下來就要介紹Yeoman 了，它由3個你所熟知的工具構(gòu)成：
-
Grunt：用于生成，預(yù)覽和自動化測試你的項目，這要特別感謝由Yeoman和grin t-contrib團(tuán)隊創(chuàng)建的許多grunt tasks。
-
Bower：前端的依賴管理工具，有了它你再也不需要手動下載和管理第三方JS庫了。
-
YO：快速生成一個新的應(yīng)用，包括配置好你的Grunt任務(wù)以及你極有可能會用到的Bower依賴。
筆者在一年以前，曾和其他一些人創(chuàng)建過一個叫ExpressStack的項目，其想法很簡單，就是要提供一些工具能夠快速生成構(gòu)建全JS的Web應(yīng)用所需要的一切。但是，這個項目夭折了，盡管如此，許多類似的項目卻如雨后春筍般涌現(xiàn)出來。
下面對這些項目作些介紹：
注意: 你可能需要裝好Yeomam(npm install -g yo)和以下一些生成器（npm install -g <generator-name>）。
1. generator-angular-fullstack
這是一個AngularJS的生成器，集成了Express,可選MongoDB。主要功能如下：
-
支持客戶端和服務(wù)端的Livereload。
-
Express server集成了grunt tasks。
-
內(nèi)建了方便的部署流程。
-
支持Jade。
可參考: http://tylerhenkel.com/creating-apps-with-angular-and-node-using-yeoman/
另一個MEAN架構(gòu)的生成器，集成了grunt-express，功能如下：
-
在generator-angular的基礎(chǔ)上，用express取代了Connect。
-
支持客戶端和服務(wù)端的Livereload。
-
使用app_grunt.js文件來啟動應(yīng)用，而在app.js中定義路由。
-
目錄結(jié)構(gòu)基本沿襲了generator-angular的風(fēng)格，只作了少許的改動。
可參考：https://github.com/Grievoushead/generator-express-angular
集成了Mongo，Express，Angular，Yeoman，Karma和Protractor（作自動測試）。
和其他的很類似，不過使用的是Mongoose和Stylus，其他的一些功能包括：
-
其目錄結(jié)構(gòu)非常容易擴(kuò)張（包含了一個TODO List的應(yīng)用例子）
-
一個配置完整的Gruntfile，集合了livereload, linting, concatenation, minification等.
-
使用exctrl來自動掛載API。
-
使用了grunt-injector，從而無需手動修改Html的layout文件，就可以自動裝載新添加的js和css。
-
使用Karma, Mocha和Chai來進(jìn)行前端的單元測試。
該生成器非常全面，添加了許多第三方的庫，包括Passport用于用戶登錄，Browserify加載js。
-
集成了AngularUI, Barbeque（用于任務(wù)隊列管理）和BootStrap
-
集成了Bower, Browserify，Express和Font Awesome
-
集成了Grunt, Handlebars, jQuery, JSHint和Karma/Mocha
-
支持LESS/LESSHat, Livereload和Lodash/Underscore
-
集成了Modernizr, MongoDB/Mongoose和Passport
該如何做出選擇?
看了這么多的生成器，自然要問，我該選擇哪一個呢？事實(shí)上，以上列表是有順序的，依據(jù)的是其與***版的Yeoman的兼容性以及維護(hù)的活躍度。
全Javascript的架構(gòu)是否適合于產(chǎn)品級的應(yīng)用呢？
不得不承認(rèn)，如果開發(fā)堆棧的每一層都能使用JavaScript將會是一件很棒的事情（至少對于原型開發(fā)來說是這樣），然而千萬要注意，不要為了追求這一目標(biāo)，而把自己而束縛住了。盡管的確有越來越多的大規(guī)模應(yīng)用都在采用類似的架構(gòu)，如Walmart、LinkedIn，但并不意味著模仿他們就一定能成功。
另一個需要注意的是，相對于其他的語言（如Ruby，Python或Java），在Node上搭建后端要困難得多。你可能要自己處理內(nèi)存泄漏，避免在事件循環(huán)中進(jìn)行耗時運(yùn)算，還要非常小心異常處理，如果這些處理不當(dāng)就很有可能會導(dǎo)致整個應(yīng)用服務(wù)器崩潰，但是這些問題在其他平臺上卻已經(jīng)處理得很好了。然而，這并不是說，Node不能運(yùn)用在生產(chǎn)環(huán)境下，當(dāng)然可以，但要格外用心。
實(shí)話實(shí)說，想要“一攬子”為Web應(yīng)用提供一個大而全的解決方案將非常困難，MEAN架構(gòu)也肯定有其局限性。在前端與后端的設(shè)計模式、原則和風(fēng)格中有大量的演化，如果你覺得PHP或Rails是更明智的選擇，那就繼續(xù)使用下去，否則的話，不妨試試MEAN，至少在當(dāng)下值得一試。
