基于Ruby On Rails如何開發高品質Web應用

這篇文章主要為大家分析了基于Ruby On Rails如何開發高品質Web應用的相關知識點，內容詳細易懂，操作細節合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學習“基于Ruby On Rails如何開發高品質Web應用”的知識吧。

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

MVC

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

在大非少數代碼內部，這種混沌不清的形態存在于model和controller之間：controller承當了太多本應由model承當的職責。其中比擬典型的例子是內嵌（多）對象表單。比如，Album和Photo之間是一對多的聯系，我們要創立一個含有多個photo的album。在 Rails 2.3之前，我們能夠會寫出類似的代碼：

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

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

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

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

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

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

REST

現今的互聯網使用曾經很難是一個獨立的個體，互聯網使用之間的交互越來越多。所以，樹立REST架構作風的互聯網使用變得越來越首要。Rails的 router很好地支持了REST作風的外部接口設計。Rails 3所做的一個很大改進就是router的改進，以強調REST作風的接口設計。

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

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

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

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

重寫之后的代碼不只更契合REST的作風，并且愈加簡約優美。

JavaScript

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

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

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

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

<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內嵌了大量的JavaScript代碼，這是一種不好的做法。Rails 3所做的其中一個改動，就是別離HTML和JavaScript代碼，生成的HTML中內嵌的JavaScript代碼消逝了：

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

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

功用

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

而客戶端緩存是離用戶近來的地點。關于客戶端緩存的一條準繩是：不要緩存靜態HTML頁面，但長久緩存一切其它文件類型。Rails對靜態文件的處置很好地表現了這條準繩。比如下面這段代碼：

stylesheet_link_tag("application")　

它生成的HTML是：

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

其中application.css?1232285206的后綴是這個文件的時間戳。那么客戶端就能夠不擔憂腸長久緩存這個靜態文靜。由于文件一旦更新，客戶端就會以為這是一個新的央求，即會去獲取最新的文件。

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

用戶體驗

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

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

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

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

安全

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

Session定置

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

reset_session　

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

跨站央求偽造

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

protect_from_forgery　:secret　=>　"123456789012345678901234567890..."　

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

日志信息泄露

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

filter_parameter_logging　:passWord　

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

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

業務模型

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

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

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

這篇文章主要為大家分析了基于Ruby On Rails如何開發高品質Web應用的相關知識點，內容詳細易懂，操作細節合理，具有一定參考價值。如果感興趣的話，不妨跟著跟隨小編一起來看看，下面跟著小編一起深入學習“基于Ruby On Rails如何開發高品質Web應用”的知識吧。