我對asp.net有一些經驗。當業務邏輯變得複雜時,您希望將存儲庫和其他業務類與主UI項目分開。如果您需要更改業務邏輯,則不需要更改ui項目。Rails:使用模型庫
在.net中我會創建一個庫項目並將業務邏輯推送到那裏,這樣我可以更改庫而不影響ui項目。
我應該在哪裏放置業務邏輯?如果我把它放在模型中,它會非常快速地變得非常混亂,因爲有很多類。
你如何構建rails應用程序需要許多類與業務邏輯?
我對asp.net有一些經驗。當業務邏輯變得複雜時,您希望將存儲庫和其他業務類與主UI項目分開。如果您需要更改業務邏輯,則不需要更改ui項目。Rails:使用模型庫
在.net中我會創建一個庫項目並將業務邏輯推送到那裏,這樣我可以更改庫而不影響ui項目。
我應該在哪裏放置業務邏輯?如果我把它放在模型中,它會非常快速地變得非常混亂,因爲有很多類。
你如何構建rails應用程序需要許多類與業務邏輯?
開發rails應用程序時的常識是將類和模塊與lib
目錄中的視圖,模型或控制器沒有直接關係。
注意,軌道3默認不自動加載它,你將不得不把在config/application.rb
如下:
config.autoload_paths += %W(#{config.root}/lib)
創建寶石可能是另一種選擇,如果你想分享多之間的業務邏輯應用程序,但它比簡單地將所有內容都放入lib
中涉及更多。
This answer如果您想了解更多信息,將是一個好的開始。
你有沒有考慮過使用Rails :: Engine?這將爲您提供一種方法來隔離一組相關的模型,控制器,視圖,路線,助手,遷移和測試。 Rails ::引擎也可能被配置爲一個寶石,因此在多個項目中使用引擎成爲一種可能性。如果你想在多個項目中使用你的引擎,寶石版本可能會派上用場。
http://edgeapi.rubyonrails.org/classes/Rails/Engine.html
我建議有一個看設計,看到底有多少人能有一個Rails ::引擎做。
https://github.com/plataformatec/devise
如果你只想要隔離較小的部分業務邏輯的,然後的ActiveSupport ::關注可能更合適一點。
http://api.rubyonrails.org/classes/ActiveSupport/Concern.html
最後的東西,我從來沒有用過,但看起來有趣的是模塊化。文檔中的示例與ActiveSupport :: Concern在本質上看起來有些相似。
class User < ActiveRecord::Base
does "user/authentication"
does "user/address"
end
https://github.com/makandra/modularity
我會跟蹤不同的答案,因爲我試圖解決同樣的問題。