2013-01-10 21 views
0

在rails中,這是創建模型,控制器和視圖的最佳實踐嗎?我知道有三種方式。Rails在生成控制器,模型和視圖方面的良好實踐

1)腳手架「一切」。

2)通過終端生成每個控制器和模型。

3)手動創建所有文件。 (在做這件事時需要小心,我必須記住關於控制器的多元化和在模型中使用單數)

目前,我遵循第三種方法,儘管它涉及一些風險。我只想知道要遵循的最佳做法是什麼。如果還有其他方法,我會很高興知道。謝謝你的時間。

P.S:我是RoR的初學者。

回答

2

我認爲腳手架是相當糟糕的,因爲它會產生很多你可能不想要的東西,我只用它來解決問題。

在實際項目中,我的公司規則書說我必須使用測試驅動開發(我喜歡)。這意味着在默認的方法中(有時我無法遵循),我從一個集成測試開始,並從中繼續。 (我建立了一個路線,然後是一個控制器方法,然後是一個視圖然後是一個模型...)

0

我相信腳手架是最好的方法,因爲它可以自動完成手動創建的整個過程。您將通過rails g scaffold myscaffold獲得您的模型,控制器,視圖和遷移,這就是爲什麼我們在rails上將ruby稱爲敏捷web開發解決方案。因此,支持開發人員快速啓動軟件或更改功能的工具可以幫助您快速變得靈活。

另一件事是,如果您可以快速引導一個項目,您可能會對優先級的重新排序做出反應更加靈活。這將有助於您的發展計劃的核心發展 更清晰和更好的方式。

0

沒有完美的解決方案。如果你手工編碼,你真的使用慣用導軌嗎? 對於「中級」程序員 - 既不希望手工編寫所有代碼,也不能依賴簡單的腳手架。你必須理解生成的代碼,但是從頭開始爲大師們留下60 wpm的完美編碼!

我推薦三個語

A.得到一個很好的開始。 Boilerplating是在Javascript和Node項目中完成它的主要方式,您可以選擇你想要的模塊(設計auth,simple_form for ajaxy表單,twitter-bootstrap等),並且開始使用一個相當負載的站點,而不是用零敲碎打的方式。這並不重要 - 只是爲了製作「PRO」網站。我仍然在尋找良好的RoR鍋爐板,railsapps(作曲家是姐妹網站)和railsbricks,以及良好的舊Rails模板,Rails Engines應該允許你這樣做。可悲的是,沒有足夠的關於如何完成的報道,因爲它需要「專家」來提供經過測試的配置,這些配置包含了最佳實踐。

B.模型優先方法。從一開始就有一個體面的模型。而不是逐個添加字段,請坐下來嘗試爲您的網站獲取3-4個核心表格,並且他們的關係已經解決。 「敏捷」的人可能會反對極簡主義的做法,但如果你有經驗,爲什麼不「設計一點點」。當然,你希望在編碼之前避免10個表格或ER圖的另一個極端!如果您有體面的模型/用戶設計,您可以提前爲您的MVP(最小可行產品)預測網站和固有模型的外觀。這當然表明你對你想要的應用看起來像有2-4個星期的遠見:)

C.測試/遷移更少的腳手架。混合方法更適用於首先進行模型生成和單獨數據遷移,然後在沒有測試或遷移選項的情況下搭建腳架。你可以看到Rails 4 for Beginners第5章爲例子。好處是 - 您不會覆蓋手工製作的模型代碼,並且讓腳手架照顧RoR魔術爲您提供的每個模型的〜5 +文件的骯髒細節。 #1.生成模型文章的標題,正文 #做耙db:創建,手動添加驗證,例如存在,最小長度等模型 #你可以在這裏做一個腳手架.. #現在添加位置和數據庫遷移摘錄ONLY(沒有手動模式的編輯也沒有腳手架全部) $導軌產生遷移add_excerpt_and_location_to_articles 摘錄:字符串位置:串 #現在OVERWRITE腳手架而不是模型.. $軌摹腳手架文章大標題:字符串位置:串摘錄:字符串 體:text published_at:datetime --skip-migration

如果你明白了 - 你可以看到SCAFFOLDING被TH治療了ROW-AWAY隨着您演變您的模型。在這個時候,你真的不在乎覆蓋控制器的細節和視圖。但是,您正在保護您的模型,並手動編輯模型之間的關係,以及詳細的驗證。

作爲一個副作用,模型優先的實用性與這種方法一致。停止腳手架之前,您可以在應用程序中獲得5-20個模型。那時候,你的代碼模型應該是相當確定的。