5

私は過去2か月間レールをいじっていましたが、これまでのところすべてが順調に進んでいますが、少し疑問がある領域が1つあります。

私はRESTfulRailsリソースの喜びについて聞き続けています。つまり、config / routersの「resource：foo」と、コントローラーでの7つの安らかなアクションです。

非常に単純なこと（たとえば、99％が「足場の生成」を実行することによって行われること）を除いて、config / routersのURLを1つずつ一致させて実行するよりも、プロジェクト機能をそのアプローチに詰め込む方が便利ではないことがわかります。必要に応じて各アクション。

しかし、私は自分が間違っていると感じ続けており、最も極端な状況を除いて、RESTfulなリソースが道のりです。

それで：

（a）誰かがこれについて意見を述べることができますか？

（b）経験豊富な鉄道関係者にとって、典型的なプロジェクトのルートの何％が：resourcesであり、何％がアクションごとにコード化されていますか？乾杯...

4

2 に答える 2

5

リソースは便利ですが、「1つのサイズですべてに対応」する機能ではありません。7つの方法では意味をなさないことがいくつかあります。

次のことができることを覚えておいてください：

  • で特定のメソッドを除外し:exceptます。
  • を含む特定のメソッドのみを含めます:only。
  • 独自のメソッドをリソースに追加します。

したがって、彼らはあなたが思うほど柔軟性がありません。しかし、これらの3つのポイントを念頭に置いた後、リソースが「正しく感じられない」場合は、スキップしてください。RESTは、通常のルーティングを置き換えることを意図したものではなく、最も一般的なユースケースを抽象化しようとするだけです。

RESTfulリソースを完全にスキップすると、大量の無料機能が失われます。賢く使うと大丈夫です。

于 2010-11-22T21:55:34.983 に答える
0

通常、私はRESTアーキテクチャを念頭に置いてプロジェクトを開始します。私はこの方法で基本的な機能を構築しますが、プロジェクト/ Webサイトが進むにつれて、RESTfulアーキテクチャーに適合しないビューをどんどん作成していきます。マーケティングサイトと並列機能は、この完璧な例です。

このアプローチに関する記事は次のとおりです。

http://ablogaboutcode.com/2010/11/22/to-be-or-not-to-be-restful-ruby-on-rails-best-practices/

始める前に、次の質問を自問してみてください。

  1. このコントローラー/ビューは、主に投稿やブログなどのオブジェクト/エンティティを扱いますか？
  2. 作成、更新、削除、編集、および新しいアクションはすべてWebで利用できるようになりますか？

ガイドラインとして、これら2つの質問に「はい」と答えた場合は、RESTから始めて、実行する可能性のある追加のアクションとビューの構成要素としてアーキテクチャを最終的に使用することを期待するのがおそらく最善です。それ以外の場合は、アクションが表示または実行する内容を最もよく表すURL（/ archives、/ tour、/ decimal-offer）を選択し、適切なHTTPプロトコル（表示にはGET、更新にはPUT、削除にはDELETE、POST）を使用していることを確認してください。作成用）。

于 2010-11-22T21:25:38.793 に答える