Question

我正在制作一个处理网站购买的购买模型，该模型将与支付网关进行交互。我的问题是如何设计界面，是否应该使用单独的类方法来完成工作，或者使用回调修补AR生命周期。

起初我正在做一些像Purchase.make_purchase（product，...）这样的类方法。但这似乎不太好。

我要实现的是一个使用模型生命周期和回调来进行购买和网关事务的解决方案。像这样：

@purchase = Purchase.new
@purchase.product = product
@purchase.user = current_user

if @purchase.save
else
end

然后我会有一个与网关对话的before_save回调：

before_save :transfer_funds

如果不成功可以暂停保存，设置@ purchase.errors [：gateway_error]

我不确定这是解决这个问题的最好办法。有什么建议吗？

Answer 1

我还没有使用它，所以我无法提供太多见解，但如果你还没有，我会看看ActiveMerchant。我不确定您的支付网关目前是什么，但如果您不使用它;你可能会得到一些想法。

编辑我意识到它没有回答这个问题，我只是觉得如果你还没有使用它，可能会给你一些想法。

我没有直接的付款处理经验，所以你可以大肆宣传我的意见。

使用生命周期方法的一个重要考虑因素是，在这种情况下，您可能最终不得不在transfer_funds方法中添加额外的逻辑，否则您可能无需这样做。例如，如果稍后可以更新Purchase，那么每次更新时您都会调用transfer_funds方法。

我不确定Purchase是否具有预授权的概念，后跟实际费用，但我认为transfer_funds应该只调用一次？您可以将其移至before_create，但这可能只能解决这一问题。

我还发现将它们移动到生命周期方法通常会在模型中添加比可能需要的更多逻辑。在过去，我发现在控制器动作中更加明确有时可以让我头疼，即使它为我添加了一个步骤，例如我需要transfer_funds所需的每个地方。

我现在尝试将我的生命周期方法保留在模型类中，仅与更新ActiveRecord模型本身相关，而不是做更多的额外工作。如果将它保留在控制器中是不可行的，我会考虑使用ActiveRecord::Observer来抽象出与transfer_funds相关联的逻辑。

希望这会给你一些想法。