1

我正在通过为一个基本上是 SO 副本的大学项目做一个应用程序来学习 Rails。考虑以下路线：

resources :questions do
  resources :answers
  post :vote_up, :vote_down, :on => :member
end

resources :answers do
  post :vote_up, :vote_down, :on => :member
end

虽然这很好用，但我确信这不是最好的方法。我在两个控制器上的vote_up和动作之间有很多重复的代码。vote_down我的规格也有很多重复。

我想知道如何以最干燥的方式解决这个问题。我想 aVotesController是必需的，但我玩弄了路由并没有得到实际的解决方案。我得到的只是一些大 URL，而不是我真正希望的。

你能指出我正确的方向吗？

4

1 回答 1

0

听起来您正在描述一个vote_controller可以在任一方向上进行投票的设备，而不是向上和向下拆分到自己的控制器中。

关于将赞成票和反对票分成自己的控制器，要问的问题是它们有多么不同。如果你有一个vote_up和vote_down控制器，他们都必须找到被投票实体的投票，添加一个新的投票，然后存储数据。无论您是投赞成票还是反对票，几乎所有事情都是一样的。事实上，我管理投票的方式是有vote一个有点像这样的类型：

   class Vote
        attr_reader :direction, :user, :timestamp
   end

这样，单一投票类型可以记录是赞成票还是反对票，以及记录投票者（因此，如果有人在拖钓，您可以一次性撤消他们的所有工作）和投票时间，即总是有用的。

然后，当您调用时，vote_controller.up_vote您创建一个具有正方向的新Vote对象，因为vote_controller.down_vote您创建一个具有负方向的对象。其他一切都是完全常见的，所以你在投票控制器中所拥有的一切都会模糊地像这样：

def vote(direction)
    myVote = vote.new(direction, Request.userId, Time.now )
    voteOnObject.votes.add(myVote)
end

def up_vote
    vote( 1 )
end

def down_vote
    vote( -1 )
end

您会注意到这与工作代码完全不同。那部分是因为我不想为你做作业，部分是因为我最近没有做太多的 Ruby，所以我有点吱吱作响。重要的是这里的原则。

如果您想适当地DRY，您还可以将其设计为可以将相同的投票控制附加到问题、答案、评论等（因此它们具有给定类型的父对象/实现给定的 mixin，其投票他们调整而不是影响模型级别的投票对象）而无需进行任何更改。

于 2013-10-25T13:45:16.777 回答