2014-10-10 71 views
1

我正在使用Rails和Resque,但这更多的是关于实际的逻辑应该与后台作业去哪里的设计问题。在哪里应该后台作业逻辑去

我有这样一个类:

class Ticket 
    # 1) should method go here? 
end 

和BG的工作是这样的:

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

然后有一个处理票务计费的方法。它使两个网络电话(其中之一将是缓慢的),所以很明显,我们需要一个后台作业

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

1)如果我把逻辑#1以上,似乎是有意义的房子逻辑支付Ticket课程的门票。然后,我将实例化BG作业中的Ticket对象。这样做的缺点是我不希望人们在背景作业之外调用pay_ticket方法,所以我需要添加一个说“只能用BG作业调用”的评论......这看起来很糟糕。

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

就像一些关于人们是否有胖背景工作或者逻辑通常停留在模型中的一般想法。或者,如果这取决于每种情况。谢谢!

+0

我知道(或者我想我知道)什么是“Ticket”,但“PayTicket”听起来不像一个对象。也许你的问题从那里开始。 – alexis 2014-10-10 18:52:01

+0

@alexis它可能是一个TicketPaymentService。这听起来像是一个对象吗? – 2014-10-10 20:53:08

+0

更好。那么服务可以做些什么?它可以支付票吗?那么支付方法就属于这种情况,特别是如果你能想象它被广义化了,并且它只依赖于Ticket的接口来获得必要的信息。 – alexis 2014-10-10 23:35:54

回答

1

这实际上取决于你想如何构建你的代码。我坚信模型设计模式,但它确实取决于每个开发人员。无论哪种方式听起来好像考虑到情况会好,所以我想我的第一个问题是,你在共享项目中开发(即其他人将在这个代码上工作吗?)

如果没有,我会说通过它在模型中保持与模型相关的逻辑尽可能接近源。

如果你是这样,揭露逻辑可能有点危险,但评论真的不是什么大问题。

如果你真的不想让任何人调用该方法,但想要让你拥有所有的功能,但不暴露pay方法遵循OOP /封装的方法,你总是可以继承的票务模式。例如:

# models/ticket.rb 
class Ticket 
    ... 
end 

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

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

+0

还有其他方法可以对此进行建模。例如一个只知道如何支付门票的新对象。 'TicketPayment.new(票).pay!'它不需要是一张票,它必须是一名工人。 – 2014-10-10 20:57:32

相关问题