1

私は、どのユーザーがどのレコードを気に入ったかを記録しているようなモデルを持っています。ユーザーが多くのモデルを好きになれるように、多態的な関連付けを使用しました。

現在、いいねを処理するためにネストされたリソースを使用しています。

POST   /items/:item_id/likes
DELETE /items/:item_id/likes/:id

like_idいくつかの理由で、より良いルートを設計することで の使用をなくしたいと考えています。これは、フラグメント ビューをキャッシュする方が簡単だからです。

itemmodel は である数少ないモデルの 1 つにすぎないことに注意してくださいlikable。可能であれば、コードの重複を避けたいと考えています。

like_id使用しないが、コントローラーでのコードの再利用を可能にするルートとコントローラーを設計する良い方法は何ですか?

可能な実装

私は次のようなルートを考えていました：

POST   /items/:item_id/like
DELETE /items/:item_id/like

ネストされたようなリソースは使用しません。代わりにlike、アイテム コントローラーにアクションを配置します。リクエストが aPOSTか a かを判断し、それDELETEに応じて動作します。ただし、これは DRY ではありません。

4

2 に答える 2

1

Railsについては必ずしもわかりませんが、Zend Frameworkでは、メソッド「LIKE」と「UNLIKE」を使用してすべてのリクエストを特定のコントローラーにルーティングするフロントコントローラープラグインを作成します。要求された後、要求しているユーザーの名前でそのリソースを「好き」または「嫌い」にするために必要なアクションを実行します。

なんで？ユーザーは、問題のリソースを「好き」または「嫌い」にしているので、「いいねを作成する」または「いいねを削除する」のではありません。確かに、バックエンドでは、「like」は作成または削除されるキャッシュまたはデータベース内のレコードですが、リソースのセマンティクスは、そのリソースを永続化するために使用されるメソッドのセマンティクスと必ずしも同等ではありません。

于 2012-09-24T07:08:39.993 に答える