なぜRuby on Rails ProfessionalはScaffoldingを使用しないのですか？
Rails以来、彼らが学んだ重要な教訓は「足場を使わない」ということです。また、ircでこの方向からの一般的なヒントを読みました。 。私の質問は、なぜ、それについての悪いことですか？ nifty_scaffolding も悪いですか？
コントローラーアクションのxmlバージョンをデフォルトで生成し、アプリケーションのフィールド名を誰にも公開し、攻撃に対してより脆弱にするため、それは悪いと思います。
足場をしない理由は何ですか？
私はRailsの経験があり、単に最終目標が単純なCRUDアクションとは程遠いという理由だけで足場を使用することはほとんどありません。しかし、足場を使用しない厳密なルールはありません。実際にはscaffolding、文字通りです。完成品ではありません。Scaffoldingは、実際の製品を構築する際にサポートします。Googleの画像で「足場」を検索すると、アイデアが得られるはずです。
scaffoldは組み込みの Railsのジェネレーター の1つにすぎないことに注意してください。 Railsジェネレーターは、いくつかの汎用コードを出力する単なるスクリプトです。ジェネレーターは非常に便利なタイムセーバーであり、すぐに自分自身を見つけることができます ジェネレーターの作成 独自のカスタムニーズ。
ほとんどの専門家は、本番コードの記述よりもテスト駆動型の開発アプローチを好むため、足場を避けています。これは、最初に失敗したテストを書き、次にテストに合格するコードを書きたいということです。これは強力なコードを生成する優れた方法ですが、非常に詳細なレベルで最適に機能します。足場は一度に多くのことを行うようであるため、特定の機能の失敗したテストを記述し、その特定の機能をパスさせるコードを記述するというタイトなループを混乱させます。足場の使いやすさを超えて、その習慣に入ることがより重要かもしれません。
それは、足場はそれ自体で非常に強力である可能性があるということです。
Rails generate scaffoldの使用を理解し、その制限に注意することが重要です。足場は、何かを素早く実行し、仮定をテストするのに役立ちます。しかし、現実の世界では、足場でモデルを作成したとしましょう
Rails generate scaffold Article title:string body:text
すごい！これでプロトタイプの準備ができました。しかし、別のフィールド「author」を追加する必要があるとしましょう。
Rails generate migration add_to_article_author author:string
rake db:migrate
テーブルの記事には新しい列がありますが、/ app/views/articlesのファイルは同じ古い状態です。つまり、フォームにはauthorフィールドなどがありません。scaffoldを再度実行すると
Rails generate scaffold Article title:string author:string body:text --skip-migration
今回は--skip-migrateを追加しました。これは以前に行われたものであり、同じテーブルを再度移行する場合、Railsは本当に文句を言います。scaffoldはファイルを上書きするように求めます。上書きすると、コントローラー/app/controllers/article_controller.rbに加えた変更や、/ app/views/article/show.html.erbやindex.html.erbなどのビューファイルも破棄されます。
価値のあるすべてのRailsアプリにはscaffoldによって作成された定型コードはありません）であるため、Railsプログラマーはアイデアをテストするためだけにscaffoldを使用する必要があります。クライアントに遊んでもらうものを提供しますが、実世界では定型的な足場コードは使用されません。
足場は、実際の運用用ではありません。これは、アプリケーションをすばやくブートストラップしてから、変更したり削除したりするためのものです。
Rails 3 scaffoldingは実際にはかなりまともですが、ネストされたリソースを処理する方法のようなものがまだ不足しており、より単純なrespond_with（respond_toは、不要な場合や歓迎されない場合に冗長性を促進します）。
デフォルトのscaffoldフォームが変更されずに動作することはまずありません。おそらく、user_idのようなデータベースの列に変換されるモデル間の関係があるでしょう。リレーションシップを持つモデルの足場を作成する場合、この列は、URLから明確に推測されるか、より使いやすい別のインターフェイスを介して選択される必要があるときに、フォームのテキストフィールドとして表示されます。
足場を生産準備完了のすぐに使えるコードの本当にありそうもない候補にするこのような多くの小さな詳細があります。確かに、足場を生成してからギャップを埋めて不要な領域をクリーンアップすることでアプリケーションを構築できます。ほとんどのRails開発者はある程度これを行うと思います。
足場は2つの理由で使用しません。
- Railsの足場はすべてをhtmlテーブルに入れます-私はそれが好きではありません
- 私は管理ページに Rails_admin gemを使用することを好むため、scaffoldコードの90％は必要ありません
あなたのxmlの懸念は、人々がscaffoldingの使用に反対する理由ではありません。私のページのXMLバージョンは、アプリが生成する必要があるルートの数を2倍にし、オーバーヘッドを少し増やすので気にしません...
これまでのところ、経験豊富なRailsプログラマーは足場を使用せず、主に正当な理由によります。初心者も足場を使用しないことを推奨します。
しばらく足を運んで喜んでいたかもしれませんが、Postモデルにpublishedブールフィールドを含めるのを忘れたことに気付いたので、テーブルに属性を追加する移行を生成します（ 「うまくいくようになった）。また、それをscaffoldが生成したフォームに追加する方法を考え出す必要があります。 Thenあなたの人生では、フォームを送信したときに更新されない理由を見つけることはできません。多くの争いと無駄な時間の後、あなたはその属性での大規模な割り当てを許可していないことがわかります足場は他の人のためにした。 Railsがどのように機能するかについて、あなたは本当に何も知らないことがわかります。
Railsを学習している場合、MとVとCを自分で構築すれば、MVCについてさらに理解できるでしょう。
足場は新しいRails=バージョンの新しいものをチェックアウトするのに非常に良いと思います（たとえば、Rails 4コントローラーでのものを許可するparams）。多くの場合、完全な足場を生成する必要はありません。