ruby-on-rails – Rails:模型中的方法太多了
TL; DR:我不知道如何组织我的逻辑域类.
我有模型“应用程序”,这个模型是应用程序的“核心”,是我“进入”和操作其他模型的方式,如: @application = Application.find(params[:application_id]) @application.payment.update_attribute 'active',true 要么 unless @application.report.status 要么 @application.set_income(params[:income][:new_income]) 所以模型付款,收入和报告基本上是空的,因为我初始化应用程序模型,并从那里我做“级联”的事情来改变“从属”模型.但现在应用程序模型有超过40种方法和600行. 我做得对吗?例如,当我想添加一个我喜欢的新付款时: payment = Payment.create params 因为ActiveRecord“知道”如何自动处理外键,所以在Application模型中.我可以使用以下方式在付款模式中创建付款: application = Application.find(application_id) params[:application_id] = application.id self.create params 但是这样,我需要手动设置Application.id,看起来更冗长,更优雅. 所以 – 如果我想减少我的应用程序模型 – 我应该在APP / lib目录中创建模块还是应该将方法移动到其他模型? 解决方法
基本上,是的,这就是你应该做的.虽然我可能会让他们成为课程而不是模块.它听起来像你所追求的模式称为“服务对象”(或有时称为“用例”).这样做是从你想要执行的特定操作中获取逻辑,并将其放入它自己的自包含类中.那个班级然后与它需要的任何模型合作.因此,您的模型仍然非常小,您的“服务类”遵循单一责任原则.然后,您的控制器通常会调用单个“服务类”来执行他们需要执行的操作 – 因此您的控制器也会保持最小化. 如果你谷歌“铁路服务对象”或类似的,你会发现很多很棒的东西,但这里有一些资源可以帮助你入门. 服务对象rails casts:https://www.youtube.com/watch?v=uIp6N89PH-c https://webuild.envato.com/blog/a-case-for-use-cases/ https://blog.engineyard.com/2014/keeping-your-rails-controllers-dry-with-services http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/(那里有一个关于服务对象的部分) 请记住,一旦开始使用服务对象,您不必总是通过应用程序模型来访问相关的模型.服务对象可能需要application_id,然后执行例如. @payment = Payment.find_by(application_id:application_id),因此您根本不需要获取应用程序实例,并且可以直接操作@payment变量. Rails让它变得“容易”和“漂亮”到相关模型的事实并不一定意味着你应该这样做. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |