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

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

MVC

我們都知曉Rails是一個MVC架構(gòu)方式的Web框架，MVC各局部的職責(zé)也很清楚。但疑問在于我們能不能真的遵照了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)嵌（多）對象表單。比如，Album和Photo之間是一對多的聯(lián)系，我們要創(chuàng)立一個含有多個photo的album。在 Rails 2.3之前，我們能夠會寫出類似的代碼：

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

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

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

然后，controller中的代碼就能夠被簡化為：

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

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

#p#

REST

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

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

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

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

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

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

JavaScript

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

很久以來，我們不斷以“腳本”的態(tài)度看待JavaScript。順序員對JavaScript的注重水平很不夠，業(yè)界對順序員的JavaScript才干要求也不高。如今，必需做出這種態(tài)度的轉(zhuǎn)變。Rails 3所做的很大一個改進就是：Unobtrusive JavaScript（非侵入式的JavaScript），以完成對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所做的其中一個改動，就是別離HTML和JavaScript代碼，生成的HTML中內(nèi)嵌的JavaScript代碼消逝了：

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

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

#p#

功用

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

而客戶端緩存是離用戶近來的地點。關(guān)于客戶端緩存的一條準(zhǔn)繩是：不要緩存靜態(tài)HTML頁面，但長久緩存一切其它文件類型。Rails對靜態(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的后綴是這個文件的時間戳。那么客戶端就能夠不擔(dān)憂腸長久緩存這個靜態(tài)文靜。由于文件一旦更新，客戶端就會以為這是一個新的央求，即會去獲取最新的文件。

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

用戶體驗

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

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

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

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

安全

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

Session定置

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

reset_session　

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

跨站央求偽造

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

protect_from_forgery　:secret　=>　"123456789012345678901234567890..."
　 

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

日志信息泄露

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

filter_parameter_logging　:passWord　
 

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

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

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

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

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

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

【編輯推薦】

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