Question

我正在使用Rails和Resque，但这更像是一个关于实际逻辑应该用于后台作业的设计问题。

我有一个这样的课程：

class Ticket
  # 1) should method go here?
end

这样的BG工作：

module Jobs
  class PayTicket
    # 2) or should the method go here?
  end
end

然后有一种处理Ticket计费的方法。它进行两次网络呼叫（其中一次会很慢），所以很明显我们需要一个后台工作

  def pay_ticket
    # calls out to stripe and another network call
  end

1）如果我将逻辑置于上面的＃1中，那么使用Ticket类支付票证的逻辑似乎是有意义的。然后我将在BG作业中实例化Ticket对象。这样做的缺点是我不希望人们在后台工作之外调用pay_ticket方法，所以我需要添加一条评论，上面写着“只用BG工作打电话”等等......这看起来很糟糕。

2）如果我把pay_ticket逻辑放在BG工作中，那么我知道它只会在那里被调用，但是它会离开那个感觉它应该去的类。

如果人们有大量的后台工作或者这种逻辑通常会留在模型中，那么就会有一些普遍的想法。或者，如果它取决于每种情况。谢谢！

Answer 1

这实际上取决于您希望如何构建代码。我是 fat </ strong>模型设计模式的坚定信徒，但它确实取决于每个开发人员。无论哪种方式听起来好像情况都好，所以我想我的第一个问题是，你是在共享项目中开发的（即，其他人是否正在研究这段代码？）

如果没有，我会在模型中说明并保持与模型相关的逻辑尽可能靠近源。

如果你是，暴露这种逻辑可能有点危险，但评论确实不是那么重要。

如果您真的不希望任何人调用该方法但希望遵循OOP /封装方法，您可以始终对Ticket模型进行子类化，以便您拥有所有功能，但不要公开pay方法。例如：

# models/ticket.rb class Ticket ... end # lib/payable_ticket.rb class PayableTicket < Ticket def pay .... end end

只是我的两分钱，但我希望有所帮助。

后台工作逻辑应该去哪里

1 个答案: