- 論壇徽章:
- 0
|
越來越多的企業(yè)開始挑選Ruby On Rails作為Web開發(fā)的框架，Rails在以前還是一些“輕量級公司”的選擇。挑選Rails的原由，是由于它高速構建的才干，是由于它是Web開發(fā)的DSL。那么挑選了Rails就代表了“高效開發(fā)”呢？其中有哪些因素影響著Web應用的質(zhì)量呢？
MVC
我們都知曉Rails是一個MVC架構方式的Web框架，MVC各局部的職責也很清楚。但疑問在于我們能不能真的遵照了MVC架構方式做到了各局部職責的明白別離？能不能遵照了單一職責的準繩？
在大非少數(shù)代碼內(nèi)部，這種混沌不清的形態(tài)存在于model和controller之間：controller承當了太多本應由model承當?shù)穆氊�。其中比擬典型的例子是內(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]
- ...
- class Album < ActiveRecord::Base
- ...
- accepts_nested_attributes_for :photos
- end
- AlbumsController
- def create
- album = Album.new params[:album]
- ...
REST
現(xiàn)今的互聯(lián)網(wǎng)使用曾經(jīng)很難是一個獨立的個體，互聯(lián)網(wǎng)使用之間的交互越來越多。所以，樹立REST架構作風的互聯(lián)網(wǎng)使用變得越來越首要。Rails的 router很好地支持了REST作風的外部接口設計。Rails 3所做的一個很大改進就是router的改進，以強調(diào)REST作風的接口設計。
REST也讓我們以資源的角度看待使用中的數(shù)據(jù)，我們的代碼設計因而也發(fā)生了一些改動。當須要添加一個invoice的PDF文件下載功用的時分，我們普通會向InvoicesController添加這么一段代碼：- InvoicesController
- def download_pdf
- ...
- send_data(generate_pdf(@invoice), :type => 'application/pdf')
- end
- def show
- ...
- respond_to do
- format format.html
- format.pdf { render :pdf => @invoice.pdf }
- end
- end
JavaScript
隨著RIA的普及以及時代的即未來臨，JavaScript的江湖位置正在與日俱增。從Google的一些使用就能夠看出業(yè)界關于 JavaScript態(tài)度的一些改動。比如Gmail，它提供了在無JavaScript支持環(huán)境下的普通版本和有JavaScript支持的全功用版本 ──這是一種漸進式加強的設計理念。但隨后幾年推出的Google Doc，曾經(jīng)完全丟棄了對無JavaScript環(huán)境的支持。從這些改動能夠看出，JavaScript曾經(jīng)是Web使用的“必需品”。甚至有人把 JavaScript稱為當今最首要的編程言語，從某種意義上這種說法也不過火。
很久以來，我們不斷以“腳本”的態(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?"%>
- <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';
- ...
- <a href="/albums/1" data-confirm="Are you sure?" data-method="delete" rel="nofollow">deletea>
功用
從一個央求（Request）的數(shù)據(jù)傳輸角度看，數(shù)據(jù)普通會閱歷從數(shù)據(jù)庫到服務器，結(jié)尾到客戶端這么一個流程（能夠尚有其它層次）。數(shù)據(jù)離客戶端越近，照應速度必須越快。因而，緩存是提高功用的一大利器。
而客戶端緩存是離用戶近來的地點。關于客戶端緩存的一條準繩是：不要緩存靜態(tài)HTML頁面，但長久緩存一切其它文件類型。Rails對靜態(tài)文件的處置很好地表現(xiàn)了這條準繩。比如下面這段代碼：
stylesheet_link_tag("application") 它生成的HTML是：- <link href="/stylesheets/application.css?1232285206" media="screen" rel="stylesheet" type="text/css"/>
Rails還在其它許多方面提供了簡便的辦法使功用優(yōu)化變得容易，比如服務端緩存機制等。但大非少數(shù)時分，功用疑問源自于我們自己的完成或許設計疑問。比如關于Active Record Query Interface的的濫用，非少數(shù)時分功用疑問都能夠議決齊備數(shù)據(jù)庫查詢來得到很大的改進。關于數(shù)據(jù)庫查詢，我們應該經(jīng)常重視多個疑問，比如：獲取的數(shù)據(jù)后果集中能不能有大量無用數(shù)據(jù)，數(shù)據(jù)庫查詢次數(shù)能不能能夠降低等等。
用戶體驗
用戶體驗是Web使用十分首要的元素，Rails作為Web開發(fā)的DSL在這方面也有許多重視。 在Web使用中我們經(jīng)常遇到的一個疑問是：submit button（提交按鈕）被屢次點擊。假設沒有被恰當處置，就會惹起表單的屢次提交。用Rails的form helper辦法能夠很容易地防止這個疑問：- submit_tag "Submit", :disable_with => "Submitting..."
Rails提供了許多便捷的辦法，讓提高用戶體驗變得十分容易。作為順序員，我們也應該對用戶體驗有更多重視，比如如何設計更好的交互來防止AJAX所帶來的種種用戶體驗疑問等等。
安全
Web使用面對著許多安全隱患，比如Session定置（Session Fixation）、跨站央求偽造（CSRF）和日志信息泄露（Logging）疑問。在Rails中我們能夠用容易到只需一行代碼的方式來防止這些安全疑問。下面是各安全隱患以及對應戰(zhàn)略。
Session定置
攻擊者議決某種方式強迫用戶運用他所掌握的Session ID，在用戶登錄之后攻擊者即可運用此Session ID竊取用戶的信息。處置方案：
reset_session
在登錄邏輯中添加此段代碼，以在登錄之前重置session，這樣便能夠防止攻擊者議決Session Fixation攻擊來獲得用戶信息。
跨站央求偽造
CSRF是指在頁面中注入一些歹意代碼或許鏈接──指向用戶運用的其它站點，比如站點A。當用戶訪問被凈化的頁面時，假設剛好站點A仍處于有效認證期，則用戶在站點A的數(shù)據(jù)就會被侵犯。處置方案：
- protect_from_forgery :secret => "123456789012345678901234567890..."
日志信息泄露
默許情況下，Rails會把一切的央求信息都記載在日志文件中。那么攻擊者就能夠議決竊取日志文件，以得到一些秘密信息，比如登錄密碼、信譽卡信息等等。處置方案：- filter_parameter_logging :passWord
Web使用還面對著許多其它安全疑問，比如SQL注入，XSS等等。我們應該更多重視Web使用所面對的安全疑問，并盡能夠防止。何況，在Rails中要防止大非少數(shù)疑問，辦法都很容易。
業(yè)務模型
結(jié)尾一個疑問雖然與Rails甚至技術的聯(lián)系并不大，但是卻聯(lián)系到一個Web使用質(zhì)量的最首要疑問：創(chuàng)立的Web使用能不能契合業(yè)務模型。我們以前在一個電子商務使用的開發(fā)流程中遇到這么一個疑問：整個購置流程的結(jié)尾一步是破費頁面，用于完成破費并生成收據(jù)的PDF文件。產(chǎn)品交付之后，客戶開端埋怨破費頁面的功用疑問：照應時間超越了容忍度。于是我們試圖改進破費頁面的功用，但由于破費頁面觸及的邏輯和業(yè)務真實過多，功用提高很難處。
但當我們重新審視破費頁面的業(yè)務邏輯時，我們發(fā)覺這個頁面原本包含了兩局部功用：破費和PDF文件的生成。而從業(yè)務角度看，PDF文件的生成不屬于破費流程，而是破費完成之后的邏輯。并且，并不是一切的用戶都須要生成PDF，強迫在破費的同時生成PDF是一種資源的糜費。所以，我們把破費頁面舉行了拆分：把生成PDF文件的功用移到了破費成功頁面，并且只需在客戶點擊相應鏈接之后才會生成PDF。容易的改動之后，不只功用疑問得到了處置，并且使用也愈加契合真實的業(yè)務流程。
當我們遇到疑問或許舉步維艱之時，停下來思索一下：我們對業(yè)務的明白能不能出現(xiàn)了疑問，我們的設計能不能出現(xiàn)了疑問。許多時分我們都能夠在這里找到答案。重新思索業(yè)務邏輯或許重新設計之后，完成能夠會容易許多，甚至也許疑問本身都曾經(jīng)不復存在了。
原文轉(zhuǎn)自：http://developer.51cto.com/art/201008/218843_2.htm |
|
免費注冊
發(fā)表于 2010-12-13 17:52
