Question

处理“多控制器动作”的Rails方式是什么？在我的应用程序中，我有一个特殊的“购物车”流程，它对几个模型有影响。基本上，当他/她登录时，流可供特殊类型的用户使用，并且如下所示：

添加用户。
- 这里可以“添加用户”。如果您了解Basecamp，则此步骤有点像将人员添加到项目中。所以在这一步我正在考虑用户资源。
这里可以为以前添加的每个用户“购买”东西。
- 这有点像基本的购物车。所以，就资源而言，我正在考虑“商店”或“购物车”。
这是确认步骤。我再次将此视为购物车的一部分。

确认后，应该发生几件事。

应该以某种方式激活在步骤1中添加的用户。也就是说，他们将无法在激活之前登录。
订单应放在第2步中的购买中。
您在步骤2中购买的“东西”是某种虚拟产品。也就是说，当用户登录时，产品显示为“邀请”。详细信息并不太重要，有点难以解释。关键是，确认后，应在数据库中创建与用户关联的邀请。

同样，系统的细节有点难以解释，但我的主要问题是如何在Rails中最好地实现这种东西。涉及多个步骤，并影响所有步骤中的多个模型。

我一直在想用某种状态机来做这件事。然后，状态机将负责在步骤或状态之间转换，并执行所需的操作。所以我想我会有一个StateMachineController或者没有模型的东西来实现主逻辑。这是可以使用的吗？似乎Rails真的偏向于RESTfull资源，但我似乎无法想到RESTfull方法，如上所述。谢谢。

Answer 1

将控制器操作视为用户导致的事件。之后发生的是通常应该与一个或多个模型相关联的逻辑。

因此，在订单模型中下订单，激活用户在用户模型中，发送邀请在邀请模型中，等等。让模特彼此了解是没有错的。当一个事件跨越多个模型时，我将一个方法放在与用户引起的事件最密切相关的方法中，可能是一个方法，如Order中的“purchase”，这就是你从Order控制器调用的方法。

因此，如果在其他模型中存在对状态的依赖，则在其中创建一些小方法来测试（如果需要），例如用户中的activated?，以及其他用于完成工作的方法，例如activate（更新用户状态），然后在邀请中“邀请”保存与用户关联的新邀请，依此类推。如果他们失败了，请确保他们提出异常。

一旦你有一堆很好的粒度方法，你可以将它们捆绑在一起，甚至将它们包装在Order#purchase方法的事务中。像

这样的东西

def purchase(user, stuff, invitee)
  Order.transaction do
    begin
      invitee.activate
      invitation = Invitation.create! {:invitee => invitee, :stuff => stuff, :invited_by => user }
      # You can't roll back an email, so do this after the others have worked without exception
      invitation.send
    rescue
      ActiveRecord::Rollback
    end
  end
end

通过在交易中完成所有操作，您的数据要么全部正确，要么不是。

某些人喜欢那样？

Rails多个控制器操作

1 个答案: