我到处读到业务逻辑属于模型而不是控制器但是限制在哪里?我正在玩个人会计应用程序.
Account Entry Operation
创建操作时,只有创建相应的条目并将其链接到帐户才有效,以便操作平衡,例如购买6件装:
o=Operation.new({:description=>"b33r", :user=>current_user, :date=>"2008/09/15"}) o.entries.build({:account_id=>1, :amount=>15}) o.valid? #=>false o.entries.build({:account_id=>2, :amount=>-15}) o.valid? #=>true
现在,在基本操作的情况下向用户显示的表格被简化以隐藏条目细节,帐户在用户请求的操作类型中选择默认值(初始帐户 - >权益到达,花费资产 - >费用,赚取收入 - >资产,借入负债 - >资产,支付债务资产 - >负债......)我想要从默认值创建的条目.
我还希望能够创建更复杂的操作(超过2个条目).对于第二个用例,我将有一个不同的形式,其中暴露了额外的复杂性.第二个用例使我无法在操作中包含借方和贷方字段并删除Entry链接.
哪种形式最好?像我一样在SimpleOperationController中使用上面的代码,或者在Operation类上定义一个新方法,这样我就可以调用Operation.new_simple_operation(params [:operation])
是不是打破了关注点的分离,实际上是从Operation类创建和操作Entry对象?
我不是在寻找关于我扭曲的会计原则的建议:)
编辑 - 似乎我没有太清楚地表达自己.我不太关心验证.我更关心创建逻辑代码应该去哪里:
假设控制器上的操作被称为花费,当使用花费时,params散列将包含:金额,日期,描述.借方和贷方账户将从被调用的操作中派生出来,但之后我必须创建所有对象.拥有它会更好吗?
#error and transaction handling is left out for the sake of clarity def spend amount=params[:operation].delete(:amount)#remove non existent Operation attribute op=Operation.new(params[:operation]) #select accounts in some way ... #build entries op.entries.build(...) op.entries.build(...) op.save end
或者在操作上创建一个方法,使上面看起来像
def spend op=Operation.new_simple_operation(params) op.save end
这肯定会给一个更薄的控制器和一个更胖的模型,但随后该模型将创建和存储其他模型的实例,这是我的问题所在.
但随后模型将创建并存储其他模型的实例,这就是我的问题所在.
这有什么问题?
如果您的"业务逻辑"声明操作必须具有一组有效的条目,那么操作类肯定没有任何错误可以了解并处理您的Entry对象.
如果你把这个太远了,有你的模型操作的事情,他们你将只能得到问题并不需要了解,像EntryHtmlFormBuilder或任何:-)