專(zhuān)攻難題：Rails、MVC及最常用的Rails命令
本文轉(zhuǎn)載自公眾號(hào)“讀芯術(shù)”(ID：AI_Discovery)。
在使用Ruby編寫(xiě)web應(yīng)用程序時(shí)，創(chuàng)始人David HeinemeierHansson說(shuō)，他只不過(guò)是將以往應(yīng)用程序的通用部分復(fù)制粘貼到新程序中。
包括他在內(nèi)，所有程序員都喜歡解決難題。嘗試解決工作領(lǐng)域內(nèi)獨(dú)有難題的唯一方法，是構(gòu)建一個(gè)抽象層，并清除腦海中所有關(guān)于基礎(chǔ)web程序的細(xì)節(jié)。使用Rails可以專(zhuān)注解決困難部分，消減重復(fù)性工作。Rails命令十分神奇，但我們必須了解每個(gè)命令的功能和編寫(xiě)過(guò)程。
Rails是什么?
Rails是一種web應(yīng)用框架。根據(jù)模型-視圖-控制器(MVC)模式，它包括了創(chuàng)建數(shù)據(jù)庫(kù)支持的web應(yīng)用程序時(shí)所需的所有內(nèi)容。MVC將應(yīng)用分為三層：模型、視圖和控制器，每一層都有特定任務(wù)。
模型-視圖-控制器(MVC)結(jié)構(gòu)示意圖
模型層
模型層代表領(lǐng)域模型(如Account、Product、Person、Post等)，概述應(yīng)用程序中特有的業(yè)務(wù)邏輯。
在Rails中，數(shù)據(jù)庫(kù)支持的模型類(lèi)源于 ActiveRecord::Base。Active Record支持用戶將數(shù)據(jù)庫(kù)行的數(shù)據(jù)表示為對(duì)象，并使用業(yè)務(wù)邏輯方法修飾這些數(shù)據(jù)對(duì)象。大多數(shù)Rails模型由數(shù)據(jù)庫(kù)支撐，模型也可以是Ruby普通類(lèi)或?qū)崿F(xiàn)由 Active Model模塊提供的一組接口的Ruby類(lèi)。
控制層
控制層的功能在于處理傳入的HTTP請(qǐng)求以及給出適當(dāng)響應(yīng)。通常這一層意味著返回HTML，但Rails控制器還可以生成XML、JSON、PDF、移動(dòng)專(zhuān)用視圖及其他格式。
控制器加載和操作模型，并呈現(xiàn)視圖模板，以便生成適當(dāng)?shù)腍TTP響應(yīng)。在Rails中，傳入要求由Action Dispatch發(fā)送至相應(yīng)控制器，控制類(lèi)來(lái)自 ActionController::Base。Action Dispatch和Action Controller一起綁定于Action Pack中。
圖源：unsplash
視圖層
視圖層由“模板”組成，主要負(fù)責(zé)提供應(yīng)用程序資源的適當(dāng)描述。模板可以有多種格式，但大多數(shù)視圖模板都是帶有內(nèi)嵌Ruby代碼的HTML(ERB 文件)。視圖通常生成控制器響應(yīng)，或生成電子郵件正文。在Rails中，視圖生成由Action View處理。
開(kāi)發(fā)一款新型Rails應(yīng)用
首先從頭構(gòu)建一個(gè)應(yīng)用程序，這步之前要確保系統(tǒng)內(nèi)裝有Ruby、RubyGems和Bundler。打開(kāi)終端導(dǎo)航到一個(gè)有權(quán)限創(chuàng)建文件的目錄。先要做的是安裝Rails并通過(guò)運(yùn)行railsnew
要從頭開(kāi)始創(chuàng)建只支持API的Rails，創(chuàng)建時(shí)--api應(yīng)在Rails應(yīng)用程序名稱(chēng)之后：railsnew<my_app_name>
通過(guò)使用 --api 旗標(biāo)，Rails能夠刪除許多默認(rèn)功能和中間件(大多是涉及無(wú)用的瀏覽器)。控制器繼承ActionController::API而非ActionController::Base，生成器會(huì)跳過(guò)生成視圖。為只支持API的Rails構(gòu)建設(shè)置資源無(wú)須作任何改變。
將所有所需gem添加至Gemfile中后開(kāi)始運(yùn)行bundle install。
- 初始化數(shù)據(jù)庫(kù)：rails db:create
- 運(yùn)行Rails服務(wù)器：rails s
Rails生成
Rails團(tuán)隊(duì)的首要目標(biāo)是高效地構(gòu)建核心應(yīng)用程序功能。Rails系統(tǒng)擁有大量生成器，能幫助用戶完成一些手動(dòng)作業(yè)。生成器除了節(jié)省時(shí)間，還有一些其他優(yōu)點(diǎn)：
- 生成器能夠?yàn)閼?yīng)用程序測(cè)試套件設(shè)置基本規(guī)格。它們會(huì)為用戶提供一些基本例子而非編寫(xiě)復(fù)雜的邏輯測(cè)試。
- 經(jīng)設(shè)置，生成器的運(yùn)行方式保持不變，這樣便能標(biāo)準(zhǔn)化代碼并幫助用戶更有效地開(kāi)發(fā)，原因在于用戶不必過(guò)多擔(dān)心手寫(xiě)代碼時(shí)可能會(huì)出現(xiàn)的拼寫(xiě)、語(yǔ)法錯(cuò)誤或其他相關(guān)漏洞。
- 生成器遵循Rails最佳操作，包括使用RESTful命名模式、刪除重復(fù)代碼、使用部分和許多其他最佳類(lèi)型設(shè)計(jì)模式。
然而，某些生成器會(huì)創(chuàng)建相當(dāng)多的代碼。如果不使用某個(gè)代碼，它就會(huì)造成應(yīng)用程序代碼不必要的混亂，從而給以后的程序員帶來(lái)困擾。所以何時(shí)使用生成器最好呢?所有Rails生成器作為命令輸入終端，并遵循下列語(yǔ)法：
- rails generate <name of generator> <options>--no-test-framework
--no-test-framework 是一個(gè)旗標(biāo)，意在提醒生成器不要為新生成模型和控制器等創(chuàng)建任何測(cè)試。當(dāng)用戶運(yùn)行自己的Rails應(yīng)用程序時(shí)則不需要旗標(biāo)，這十分有助于快速建立測(cè)試套件。
為了提高效率，Rails將generate 方法簡(jiǎn)化為g，因此上述CLI命令可以簡(jiǎn)化為：
- rails g <name of generator> <options>--no-test-framework
圖源：unsplash
下列是Rails提供的主要生成器。筆者將分別舉例說(shuō)明：
遷移生成器
Rails有一組遵守規(guī)范的優(yōu)質(zhì)遷移生成器，能夠有效管理數(shù)據(jù)庫(kù)模式。繪制域模型后可以進(jìn)行下一步。首先使用案例庫(kù)應(yīng)用程序中的數(shù)據(jù)庫(kù)遷移并更新 painters 表。運(yùn)用下列命令在表中添加一列，將其命名為portrait：
- railsg migration add_portrait_to_painters portrait:string --no-test-framework
終端顯示創(chuàng)建了遷移文件20200928055457_add_portrait_to_painters.rb.。由于遷移文件名不得重復(fù)，生成器會(huì)在文件名前加上時(shí)間戳。神奇的事情發(fā)生了——打開(kāi)db/migrat 目錄中創(chuàng)建的文件，它現(xiàn)在應(yīng)該是這樣：
- class AddPortraitToPainters < ActiveRecord::Migration[6.0]
- def change
- add_column :painters, :portrait,:string
- end
- end
注意到生成器的作用了嗎?它自動(dòng)感知到用戶想添加一個(gè)新的列，構(gòu)建了add_column 方法調(diào)用。這是如何做到的?
實(shí)踐證明，命名遷移文件的方法至關(guān)重要。通過(guò)在名稱(chēng)前加上add_文本，它向遷移生成器發(fā)送了一個(gè)信號(hào)，即這種模式更改的目的是向表中添加一列/多列。
那么它是如何知道用戶想在哪個(gè)表上添加的呢?它將_painters 文本附加到遷移名稱(chēng)的末尾，以此告訴Rails用戶想更改的表格是 painters 表。最后，通過(guò)在命令末尾添加 portrait:string 文本告知生成器新的列的名稱(chēng)為portrait，數(shù)據(jù)類(lèi)型為 string。
用戶可以通過(guò)運(yùn)行rails db:migrate 更新數(shù)據(jù)庫(kù)模式，該模式也會(huì)反映出這次變更。
刪除列則可以運(yùn)行另外一個(gè)遷移：
- railsg migration remove_portrait_from_painters portrait:string
如果打開(kāi)此遷移文件則會(huì)看到下列代碼：
- class RemovePortraitToPainters < ActiveRecord::Migration[6.0]
- def change
- remove_column :painters, :portrait,:string
- end
- end
運(yùn)行rails db:migrate 后，模式也會(huì)得到更新。當(dāng)需要運(yùn)行任何未決遷移時(shí)可以使用這一命令。
- railsdb:migrate:reset：它會(huì)刪除數(shù)據(jù)庫(kù)信息，在新的數(shù)據(jù)庫(kù)運(yùn)行遷移并重新加載種子數(shù)據(jù)。
- railsdb:seed：將數(shù)據(jù)從文件:db/seeds.rb加載到數(shù)據(jù)庫(kù)中。這種方法對(duì)用Rails項(xiàng)目所需的初始數(shù)據(jù)填充數(shù)據(jù)庫(kù)十分有用。
- railsdb:rollback：回滾上次執(zhí)行的遷移。它會(huì)撤銷(xiāo)上一次遷移，接著用戶便可編輯文件并重新運(yùn)行 rails db:migrate 。注意，進(jìn)行過(guò)程中謹(jǐn)慎使用這一命令，因?yàn)樗鼧O具破壞性，很有可能造成數(shù)據(jù)丟失。運(yùn)行時(shí)一定確保自己完全清楚運(yùn)行后的結(jié)果。
模型生成器
這是一種經(jīng)常使用的生成器類(lèi)型。它適用于編寫(xiě)創(chuàng)建模型和關(guān)聯(lián)數(shù)據(jù)庫(kù)表所需的核心代碼，且不會(huì)使應(yīng)用程序過(guò)于復(fù)雜。一般來(lái)說(shuō)需要模型名稱(chēng)(單數(shù)和首字母大寫(xiě))和模型參數(shù)。
接下來(lái)為帶有 name、bio和 genre列的Painter 應(yīng)用程序添加一個(gè)新模型，可以通過(guò)以下CLI命令使用模型生成器：
- railsg model Painter name:string genre:string bio:text
如果數(shù)據(jù)類(lèi)型為字符串，則不需要在列名后指定類(lèi)型，因?yàn)樗悄J(rèn)數(shù)據(jù)類(lèi)型。因此如下：
- railsg model Painter name genre bio:text
因其水平較高，這一步已經(jīng)創(chuàng)建了：
- 添加一個(gè)表格和name、genre和 bio列的數(shù)據(jù)庫(kù)遷移
- 繼承ApplicationRecord (自Rails 5起)的模型文件
我們接下來(lái)創(chuàng)建另一個(gè)屬于Painter的模型Painting：
- railsg model Painting name image painter:belongs_to
切記首先生成具有has_many宏命令的代碼;在運(yùn)行遷移時(shí)只有帶有belongs_to 的代碼有用，否則會(huì)得到錯(cuò)誤代碼：
- ActiveRecord::StatementInvalid:PG::UndefinedTable: ERROR: relation "<some table name>" doesnot exist
運(yùn)行這一生成器會(huì)創(chuàng)建出一個(gè)遷移文件和 Painter 和Painting模型。這一特定的生成器創(chuàng)建了一些具有單命令的不同的功能，且僅用最簡(jiǎn)單的代碼就生成出來(lái)。接著轉(zhuǎn)向自己的模型，確保建立適當(dāng)關(guān)系(has_many, belongs_to)。
下一步是創(chuàng)建一個(gè)遷移：rails db:create 和 rails db:migrate來(lái)遷移表格。用戶可以在控制臺(tái)中測(cè)試連接，只需要運(yùn)行rails c并創(chuàng)建一些新的例子，不論正確與否都可以測(cè)試驗(yàn)證;接下來(lái)測(cè)試關(guān)聯(lián)度(如Painter.all.first.painting能夠檢查第一個(gè)painter的painting)
圖源：unsplash
控制生成器
運(yùn)行rails g controller 命令會(huì)提供一個(gè)控制文件(用于添加適當(dāng)操作)和相應(yīng)的視圖文件夾：
- railsg controller paintings
資源生成器
如果用戶在在創(chuàng)建API過(guò)程中使用前端MVC架構(gòu)，或只想手動(dòng)創(chuàng)建視圖，resource生成器是編寫(xiě)代碼的一個(gè)優(yōu)選。創(chuàng)建Painting資源：
- railsg resource Painting name image painter:belongs_to
因?yàn)闆](méi)有為name和image 編寫(xiě)數(shù)據(jù)類(lèi)型，因此默認(rèn)情況下它是一個(gè)字符串。添加 painter:belongs_to 來(lái)指定兩個(gè)表格的關(guān)系，并在paintings表格中設(shè)置一列 painter_id。也可以使用 references編寫(xiě)上述命令(結(jié)果一樣)：
- railsg resource Painting name image painter:references
這是為不同模型編寫(xiě)相同命令的另一個(gè)例子：
- railsg resource Answer content correct_answer:boolean question:belongs_to
憑借生成器，目前的應(yīng)用程序擁有什么?
- 一個(gè)遷移文件，能夠在生成器中為傳遞給它的屬性創(chuàng)建一個(gè)新的數(shù)據(jù)庫(kù)表
- 繼承ApplicationRecord的模型文件(從Rails 5開(kāi)始，見(jiàn)上述注意事項(xiàng))
- 繼承了ApplicationController的控制器文件
- 不帶有視圖模板文件的視圖目錄
- 視圖helper文件
- 用于該控制器的特定JavaScripts的Coffeescript文件
- 用于控制器樣式的 scss文件
- routes.rb文件內(nèi)的完整資源調(diào)用
resource生成器是一種智能生成器，創(chuàng)建全功能資源所需的一些核心功能，同時(shí)不會(huì)導(dǎo)致過(guò)多代碼膨脹。
路由
圖源：unsplash
最后一項(xiàng)可能不太常見(jiàn)。通常resources:paintings被視作為一個(gè)“魔法”路由，它包含在應(yīng)用程序中執(zhí)行CRUD所需的全部RESTful路由。那么resources:paintings會(huì)轉(zhuǎn)化成什么?用濾波器運(yùn)行 rake routes 會(huì)比較簡(jiǎn)單，這樣就只會(huì)呈現(xiàn)paintings的路由：
- rake routes | grep painting
resources自動(dòng)創(chuàng)建每個(gè)路由并使其對(duì)控制器可用。打開(kāi)paintings_controller.rb文件會(huì)很有趣：路由列表中出現(xiàn)的操作都不存在。它創(chuàng)建的代碼非常少，只需添加應(yīng)用程序需要的功能。
Scaffold生成器
- rails g scaffold User username:string
正確的命令可以創(chuàng)建有用的文件，設(shè)置路由和宏命令。希望本文能讓你理解Rails的神奇之處，MVC的定義和命令執(zhí)行。
