越來(lái)越多的企業(yè)開(kāi)始挑選Ruby On Rails作為Web開(kāi)發(fā)的框架，Rails在以前還是一些“輕量級(jí)公司”的選擇。挑選Rails的原由，是由于它高速構(gòu)建的才干，是由于它是Web開(kāi)發(fā)的DSL。那么挑選了Rails就代表了“高效開(kāi)發(fā)”呢？其中有哪些因素影響著Web應(yīng)用的質(zhì)量呢？

51CTO推薦專(zhuān)題： Ruby On Rails開(kāi)發(fā)教程

MVC

我們都知曉Rails是一個(gè)MVC架構(gòu)方式的Web框架，MVC各局部的職責(zé)也很清楚。但疑問(wèn)在于我們能不能真的遵照了MVC架構(gòu)方式做到了各局部職責(zé)的明白別離？能不能遵照了單一職責(zé)的準(zhǔn)繩？

在大非少數(shù)代碼內(nèi)部，這種混沌不清的形態(tài)存在于model和controller之間：controller承當(dāng)了太多本應(yīng)由model承當(dāng)?shù)穆氊?zé)。其中比擬典型的例子是內(nèi)嵌（多）對(duì)象表單。比如，Album和Photo之間是一對(duì)多的聯(lián)系，我們要?jiǎng)?chuàng)立一個(gè)含有多個(gè)photo的album。在 Rails 2.3之前，我們能夠會(huì)寫(xiě)出類(lèi)似的代碼：

AlbumsController　  
　def　create　  
album　=　Album.new　params[:album]　  
album.photos　<<　Photo.new　params[:album][:photo]　  
...　 

假設(shè)是一個(gè)觸及更多品種型對(duì)象的表單，這里的代碼能夠會(huì)愈加龐雜。但在AlbumsController內(nèi)部，我們真實(shí)想關(guān)心的只是Album的創(chuàng)立，而不是Photo或其它關(guān)聯(lián)對(duì)象的創(chuàng)立。并且從Album的角度看，創(chuàng)立流程中photo跟其它attributes沒(méi)有區(qū)別，應(yīng)該得到一致地處置。Rails 2.3之后，我們就能夠很容易地抵達(dá)這個(gè)目標(biāo)。在Album內(nèi)部做這樣的聲明：

class　Album　<　ActiveRecord::Base　  
　...　  
　accepts_nested_attributes_for　:photos　  
end　 

然后，controller中的代碼就能夠被簡(jiǎn)化為：

AlbumsController　  
　def　create　  
album　=　Album.new　params[:album]　  
...　 

從這個(gè)例子中能夠看到Rails在推進(jìn)MVC三局部之間職責(zé)明白上所做的全力和提高。許多人能夠會(huì)說(shuō)，我們的代碼沒(méi)有這樣的疑問(wèn)。但MVC三局部之間職責(zé)開(kāi)端模糊，往往出如今業(yè)務(wù)邏輯變得龐雜之后。我們應(yīng)該經(jīng)常審視我們的代碼，做到真實(shí)的職責(zé)單一。

#p#

REST

現(xiàn)今的互聯(lián)網(wǎng)使用曾經(jīng)很難是一個(gè)獨(dú)立的個(gè)體，互聯(lián)網(wǎng)使用之間的交互越來(lái)越多。所以，樹(shù)立REST架構(gòu)作風(fēng)的互聯(lián)網(wǎng)使用變得越來(lái)越首要。Rails的 router很好地支持了REST作風(fēng)的外部接口設(shè)計(jì)。Rails 3所做的一個(gè)很大改進(jìn)就是router的改進(jìn)，以強(qiáng)調(diào)REST作風(fēng)的接口設(shè)計(jì)。

REST也讓我們以資源的角度看待使用中的數(shù)據(jù)，我們的代碼設(shè)計(jì)因而也發(fā)生了一些改動(dòng)。當(dāng)須要添加一個(gè)invoice的PDF文件下載功用的時(shí)分，我們普通會(huì)向InvoicesController添加這么一段代碼：

InvoicesController　  
　def　download_pdf　  
...　  
send_data(generate_pdf(@invoice),　:type　=>　'application/pdf')　  
　end　 

這段代碼至少存在兩個(gè)疑問(wèn)：第一個(gè)疑問(wèn)，就是我們先面所述的職責(zé)明白疑問(wèn)。PDF的generate屬于Invoice而不是controller 的職責(zé)，所以我們應(yīng)該把PDF生成的邏輯移到Invoice內(nèi)部。第二個(gè)疑問(wèn)，則是語(yǔ)義能不能恰當(dāng)?shù)囊蓡?wèn) 。假設(shè)我們以資源的角度看待Invoice的話(huà)，PDF跟Html或許XML一樣，只是Invoice的另一種表現(xiàn)方式而已。而表現(xiàn)一個(gè)資源，在show action中處置最為恰當(dāng)。重寫(xiě)之后，代碼如下：

def　show　  
　...　  
　respond_to　do　format　  
format.html　  
format.pdf　{　render　:pdf　=>　@invoice.pdf　}　  
　end　  
end　 

重寫(xiě)之后的代碼不只更契合REST的作風(fēng)，并且愈加簡(jiǎn)約優(yōu)美。

JavaScript

隨著RIA的普及以及時(shí)代的即未來(lái)臨，JavaScript的江湖位置正在與日俱增。從Google的一些使用就能夠看出業(yè)界關(guān)于 JavaScript態(tài)度的一些改動(dòng)。比如Gmail，它提供了在無(wú)JavaScript支持環(huán)境下的普通版本和有JavaScript支持的全功用版本 ──這是一種漸進(jìn)式加強(qiáng)的設(shè)計(jì)理念。但隨后幾年推出的Google Doc，曾經(jīng)完全丟棄了對(duì)無(wú)JavaScript環(huán)境的支持。從這些改動(dòng)能夠看出，JavaScript曾經(jīng)是Web使用的“必需品”。甚至有人把 JavaScript稱(chēng)為當(dāng)今最首要的編程言語(yǔ)，從某種意義上這種說(shuō)法也不過(guò)火。

很久以來(lái)，我們不斷以“腳本”的態(tài)度看待JavaScript。順序員對(duì)JavaScript的注重水平很不夠，業(yè)界對(duì)順序員的JavaScript才干要求也不高。如今，必需做出這種態(tài)度的轉(zhuǎn)變。Rails 3所做的很大一個(gè)改進(jìn)就是：Unobtrusive JavaScript（非侵入式的JavaScript），以完成對(duì)HTML和JavaScript代碼的別離。比如：

<%=　link_to　"delete",　album_path(@album),　:method　=>　:delete,　:confirm　=>　"Are　you　sure?"%>
　 

在Rails 3之前，它生成的代碼應(yīng)為（代碼舉行了省略）：

<a　href="/albums/1"　onclick="if　(confirm('Are　you　sure?'))　{　  
    var　f　=　document.createElement('form');　  
    f.style.display　=　'none';　this.parentNode.appendChild(f);　  
    f.method　=　'POST';　...　 

能夠看到，生成的HTML內(nèi)嵌了大量的JavaScript代碼，這是一種不好的做法。Rails 3所做的其中一個(gè)改動(dòng)，就是別離HTML和JavaScript代碼，生成的HTML中內(nèi)嵌的JavaScript代碼消逝了：

<a　href="/albums/1"　data-confirm="Are　you　sure?"　data-method="delete"　rel="nofollow">deletea>
　 

那么JavaScript代碼到哪里去了？它們都被放到了一個(gè)叫做Rails.js的文件中。跟服務(wù)端MVC要求職責(zé)別離一樣，這個(gè)準(zhǔn)繩也應(yīng)該表如今客戶(hù)端的代碼上。HTML、Css和JavaScript應(yīng)該職責(zé)明白地各自傲責(zé)數(shù)據(jù)、顯示和行為。同時(shí)，這種別離也對(duì)順序員的JavaScript才干提出了更高的要求。

#p#

功用

從一個(gè)央求（Request）的數(shù)據(jù)傳輸角度看，數(shù)據(jù)普通會(huì)閱歷從數(shù)據(jù)庫(kù)到服務(wù)器，結(jié)尾到客戶(hù)端這么一個(gè)流程（能夠尚有其它層次）。數(shù)據(jù)離客戶(hù)端越近，照應(yīng)速度必須越快。因而，緩存是提高功用的一大利器。

而客戶(hù)端緩存是離用戶(hù)近來(lái)的地點(diǎn)。關(guān)于客戶(hù)端緩存的一條準(zhǔn)繩是：不要緩存靜態(tài)HTML頁(yè)面，但長(zhǎng)久緩存一切其它文件類(lèi)型。Rails對(duì)靜態(tài)文件的處置很好地表現(xiàn)了這條準(zhǔn)繩。比如下面這段代碼：

stylesheet_link_tag("application")
　 

它生成的HTML是：

<link　href="/stylesheets/application.css?1232285206"　media="screen"　rel="stylesheet"　type="text/css"/>
　 

其中application.css?1232285206的后綴是這個(gè)文件的時(shí)間戳。那么客戶(hù)端就能夠不擔(dān)憂(yōu)腸長(zhǎng)久緩存這個(gè)靜態(tài)文靜。由于文件一旦更新，客戶(hù)端就會(huì)以為這是一個(gè)新的央求，即會(huì)去獲取最新的文件。

Rails還在其它許多方面提供了簡(jiǎn)便的辦法使功用優(yōu)化變得容易，比如服務(wù)端緩存機(jī)制等。但大非少數(shù)時(shí)分，功用疑問(wèn)源自于我們自己的完成或許設(shè)計(jì)疑問(wèn)。比如關(guān)于Active Record Query Interface的的濫用，非少數(shù)時(shí)分功用疑問(wèn)都能夠議決齊備數(shù)據(jù)庫(kù)查詢(xún)來(lái)得到很大的改進(jìn)。關(guān)于數(shù)據(jù)庫(kù)查詢(xún)，我們應(yīng)該經(jīng)常重視多個(gè)疑問(wèn)，比如：獲取的數(shù)據(jù)后果集中能不能有大量無(wú)用數(shù)據(jù)，數(shù)據(jù)庫(kù)查詢(xún)次數(shù)能不能能夠降低等等。

用戶(hù)體驗(yàn)

用戶(hù)體驗(yàn)是Web使用十分首要的元素，Rails作為Web開(kāi)發(fā)的DSL在這方面也有許多重視。 在Web使用中我們經(jīng)常遇到的一個(gè)疑問(wèn)是：submit button（提交按鈕）被屢次點(diǎn)擊。假設(shè)沒(méi)有被恰當(dāng)處置，就會(huì)惹起表單的屢次提交。用Rails的form helper辦法能夠很容易地防止這個(gè)疑問(wèn)：

submit_tag　"Submit",　:disable_with　=>　"Submitting..."
　 

代碼中的:disable_with選項(xiàng)的作用是：在button被點(diǎn)擊之后把它disable掉，并且把button的文字交流成“Submitting”。一個(gè)容易的選項(xiàng)帶來(lái)了顯而易見(jiàn)的益處：不只防止了屢次點(diǎn)擊的疑問(wèn)，并且顯式地通知了用戶(hù)表單正在被提交當(dāng)中。

Rails提供了許多便捷的辦法，讓提高用戶(hù)體驗(yàn)變得十分容易。作為順序員，我們也應(yīng)該對(duì)用戶(hù)體驗(yàn)有更多重視，比如如何設(shè)計(jì)更好的交互來(lái)防止AJAX所帶來(lái)的種種用戶(hù)體驗(yàn)疑問(wèn)等等。

安全

Web使用面對(duì)著許多安全隱患，比如Session定置（Session Fixation）、跨站央求偽造（CSRF）和日志信息泄露（Logging）疑問(wèn)。在Rails中我們能夠用容易到只需一行代碼的方式來(lái)防止這些安全疑問(wèn)。下面是各安全隱患以及對(duì)應(yīng)戰(zhàn)略。

Session定置

攻擊者議決某種方式強(qiáng)迫用戶(hù)運(yùn)用他所掌握的Session ID，在用戶(hù)登錄之后攻擊者即可運(yùn)用此Session ID竊取用戶(hù)的信息。處置方案：

reset_session　

在登錄邏輯中添加此段代碼，以在登錄之前重置session，這樣便能夠防止攻擊者議決Session Fixation攻擊來(lái)獲得用戶(hù)信息。

跨站央求偽造

CSRF是指在頁(yè)面中注入一些歹意代碼或許鏈接──指向用戶(hù)運(yùn)用的其它站點(diǎn)，比如站點(diǎn)A。當(dāng)用戶(hù)訪問(wèn)被凈化的頁(yè)面時(shí)，假設(shè)剛好站點(diǎn)A仍處于有效認(rèn)證期，則用戶(hù)在站點(diǎn)A的數(shù)據(jù)就會(huì)被侵犯。處置方案：

protect_from_forgery　:secret　=>　"123456789012345678901234567890..."
　 

此代碼會(huì)在非get央求中添加一個(gè)security token，假設(shè)token不一致，則央求將失敗。這種方式能夠有效防止CSRF，當(dāng)然前提是我們正確地運(yùn)用了HTTP method。

日志信息泄露

默許情況下，Rails會(huì)把一切的央求信息都記載在日志文件中。那么攻擊者就能夠議決竊取日志文件，以得到一些秘密信息，比如登錄密碼、信譽(yù)卡信息等等。處置方案：

filter_parameter_logging　:passWord　
 

這行代碼就能夠過(guò)濾那些不期盼被日志文件記載的信息，比如password等，從而防止議決日志來(lái)泄露敏感信息。

Web使用還面對(duì)著許多其它安全疑問(wèn)，比如SQL注入，XSS等等。我們應(yīng)該更多重視Web使用所面對(duì)的安全疑問(wèn)，并盡能夠防止。何況，在Rails中要防止大非少數(shù)疑問(wèn)，辦法都很容易。

業(yè)務(wù)模型

結(jié)尾一個(gè)疑問(wèn)雖然與Rails甚至技術(shù)的聯(lián)系并不大，但是卻聯(lián)系到一個(gè)Web使用質(zhì)量的最首要疑問(wèn)：創(chuàng)立的Web使用能不能契合業(yè)務(wù)模型。我們以前在一個(gè)電子商務(wù)使用的開(kāi)發(fā)流程中遇到這么一個(gè)疑問(wèn)：整個(gè)購(gòu)置流程的結(jié)尾一步是破費(fèi)頁(yè)面，用于完成破費(fèi)并生成收據(jù)的PDF文件。產(chǎn)品交付之后，客戶(hù)開(kāi)端埋怨破費(fèi)頁(yè)面的功用疑問(wèn)：照應(yīng)時(shí)間超越了容忍度。于是我們?cè)噲D改進(jìn)破費(fèi)頁(yè)面的功用，但由于破費(fèi)頁(yè)面觸及的邏輯和業(yè)務(wù)真實(shí)過(guò)多，功用提高很難處。

但當(dāng)我們重新審視破費(fèi)頁(yè)面的業(yè)務(wù)邏輯時(shí)，我們發(fā)覺(jué)這個(gè)頁(yè)面原本包含了兩局部功用：破費(fèi)和PDF文件的生成。而從業(yè)務(wù)角度看，PDF文件的生成不屬于破費(fèi)流程，而是破費(fèi)完成之后的邏輯。并且，并不是一切的用戶(hù)都須要生成PDF，強(qiáng)迫在破費(fèi)的同時(shí)生成PDF是一種資源的糜費(fèi)。所以，我們把破費(fèi)頁(yè)面舉行了拆分：把生成PDF文件的功用移到了破費(fèi)成功頁(yè)面，并且只需在客戶(hù)點(diǎn)擊相應(yīng)鏈接之后才會(huì)生成PDF。容易的改動(dòng)之后，不只功用疑問(wèn)得到了處置，并且使用也愈加契合真實(shí)的業(yè)務(wù)流程。

當(dāng)我們遇到疑問(wèn)或許舉步維艱之時(shí)，停下來(lái)思索一下：我們對(duì)業(yè)務(wù)的明白能不能出現(xiàn)了疑問(wèn)，我們的設(shè)計(jì)能不能出現(xiàn)了疑問(wèn)。許多時(shí)分我們都能夠在這里找到答案。重新思索業(yè)務(wù)邏輯或許重新設(shè)計(jì)之后，完成能夠會(huì)容易許多，甚至也許疑問(wèn)本身都曾經(jīng)不復(fù)存在了。

【編輯推薦】

1. 跑起來(lái)吧 Ruby on Rails開(kāi)發(fā)初體驗(yàn)
2. Ruby on Rails性能優(yōu)化七劍
3. Ruby on Rails應(yīng)用技巧全解析
4. 總結(jié)各種Ruby on Rails命令
5. Ruby on Rails驗(yàn)證輸入技術(shù)講解