这篇文章主要为大家分析了基于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应用”的知识吧。
