2

リソースをネストするかどうかを決定するために、どのような基準を使用しますか?

過去に、関連するリソース (親) にスコープを設定しないと、リソースに対するインデックス アクションが意味をなさない場合に、ネストすることを選択しました。

上記の基準を書いていても、せいぜいあいまいであることに気付きます。

同僚は次のように述べています。

関連付けられたモデルの関係を URL 構造で視覚的にキャプチャするため、リソースをネストします。また、URL を簡単に変更して、投稿だけに戻ることができます。/posts/123/offers/555 が表示された場合 -- /posts/123 にアクセスして自分の投稿を表示できることがわかります。/offers/555 を見ただけのように、手動でサイトをナビゲートする以外に投稿に戻る方法はありません。

私にとって、ユーザーによる URL の操作は、アプリケーションのアーキテクチャに影響を与えるべきではなく、ネストされたリソースは可能な限り避けるべきであるという一般的に保持されている原則であると私が理解するものに反します。さらに、この議論は複数レベルのネストをサポートしているように見えますが、これもまた、私が読んだほとんどすべての記事が反対のアドバイスをしています。

あなたの経験は何ですか？

4

1 に答える 1

0

あなたが最初に言ったように、ルートの後のものが前者なしでは意味をなさない場合、私はルートを入れ子にします。ブログのコメントはその下にネストされresources articlesます。なぜなら、個々のコメントをそれ自身のページに表示したい (理由は誰にもわかりませんが...) かもしれませんが、コメントは記事に属しているからです。

これにはコントローラーの実装もあります。記事を知っている場合は、その記事に限定された特定のコメントを見つけることができます。これにより、より効果的なクエリが作成されます。

また、ルートをいじるユーザーに対処しなければならないというあなたの同僚の意見は正しかったのですが、彼の理由は間違っていました。それは彼らの便宜のためではなく、彼らの安全のためです。

ユーザーと注文を含む Amazon のようなアプリを考えてみましょう。もし私がそうならusers/5/orders/2、私は「ちょっと、その5を4に変更して、他の誰かの注文を見ることができます!」と思います. 注文のスコープを設定しないと、ユーザーに表示を許可するためのコントローラー レベルのロジックが非常に複雑にorders/2なります。ユーザーへのスコープcurrent_user.orders.find(params[:id])は、注文コントローラーで許可されます。現在のユーザーは認証に基づいて見つけることができるため、URL の ID を交換して他のユーザーになることはできません。

于 2012-05-12T02:14:12.790 に答える