2011-09-14 27 views
0

我正在製作一個處理網站購買的購買模式,它將與支付網關交互。我的問題是關於如何設計接口,是否應該使用單獨的類方法來完成工作,或者使用回調修補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]

我不確定這是解決此問題的最佳方法。有什麼建議?

回答

0

我還沒有使用它,所以我不能給予太多的見解,但我會看看ActiveMerchant,如果你還沒有。我不確定您的付款通道現在是什麼,但是如果您沒有使用它,你可能會有一些想法。

編輯我意識到它沒有回答這個問題,我只是想,如果你還沒有使用它,可能會給你一些想法。

我沒有直接的付款處理經驗,所以你可以把我的意見與大粒鹽。

我使用生命週期方法的最大考慮是您可能最終必須在transfer_funds方法中放置額外的邏輯,否則您可能不需要這種方法。例如,如果稍後可以更新Purchase,則每次更新時都會調用transfer_funds方法。

我不確定Purchase是否具有預先授權後跟實際費用的概念,但我認爲transfer_funds應該只能被調用一次?您也許可以將其移至before_create,但這隻能解決這一情況。

我還發現,將它們移動到生命週期方法中往往會向可能需要的模型中添加更多的邏輯。在過去,我發現在控制器操作中更加明確有時可以讓我頭疼,即使它增加了一個步驟,例如我需要爲transfer_funds做好每一個地方。

我現在嘗試在模型類中保留我的生命週期方法,這隻與更新ActiveRecord模型本身有關,並且沒有做太多的額外工作。如果將它保存在控制器中是不可行的,我會考慮使用ActiveRecord::Observer來抽象出與transfer_funds相關的邏輯。

希望這給你一些想法。

+0

我是使用活躍的商人,但這不是問題;) – pixelearth

+0

瞭解,我更新了我的答案,給我的生活週期方法的個人經驗,希望它可以給你一些想法。 –

+0

我使用生命週期方法完成了85%的模型。我和你之前創建的結果一樣,而不是在保存之前。你可以在這裏看到它(未完成)http://pastie.org/2541360 – pixelearth