为了瘦控制器，rails 模型应该关注其他模型吗? [英] Should rails models be concerned with other models for the sake of skinny controllers?

问题描述

我到处都读到业务逻辑属于模型而不属于控制器，但限制在哪里?我正在玩一个个人会计应用程序.

I read everywhere that business logic belongs in the models and not in controller but where is the limit? I am toying with a personnal accounting application.

Account
Entry
Operation

当创建一个操作时，只有当相应的条目被创建并链接到帐户时才有效，以便操作平衡，例如购买 6 件:

When creating an operation it is only valid if the corresponding entries are created and linked to accounts so that the operation is balanced for exemple buy a 6-pack :

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

现在在基本操作的情况下向用户显示的表单被简化以隐藏条目详细信息，根据用户请求的操作类型(初始化账户 -> 股权，支出资产 -> 费用，赚取收入 -> 资产，借入负债 -> 资产，支付债务资产 -> 负债 ...)我想要从默认值创建的条目.

Now the form shown to the user in the case of basic operations is simplified to hide away the entries details, the accounts are selected among 5 default by the kind of operation requested by the user (intialise account -> equity to accout, spend assets->expenses, earn revenues->assets, borrow liabilities->assets, pay debt assets->liabilities ...) I want the entries created from default values.

我还希望能够创建更复杂的操作(超过 2 个条目).对于这第二个用例，我将有一个不同的形式，其中暴露了额外的复杂性.第二个用例阻止我在操作中包含借方和贷方字段并摆脱条目链接.

I also want to be able to create more complex operations (more than 2 entries). For this second use case I will have a different form where the additional complexity is exposed.This second use case prevents me from including a debit and credit field on the Operation and getting rid of the Entry link.

哪种形式最好?像我现在一样在 SimpleOperationController 中使用上面的代码，或者在 Operation 类上定义一个新方法，以便我可以调用 Operation.new_simple_operation(params[:operation])

Which is the best form ? Using the above code in a SimpleOperationController as I do for the moment, or defining a new method on the Operation class so I can call Operation.new_simple_operation(params[:operation])

从 Operation 类中实际创建和操作 Entry 对象是否打破了关注点分离?

Isn't it breaking the separation of concerns to actually create and manipulate Entry objects from the Operation class ?

我不是在寻求关于我扭曲的会计原则的建议:)

I am not looking for advice on my twisted accounting principles :)

edit -- 好像我表达的不太清楚.我不太关心验证.我更关心创建逻辑代码应该去哪里:

edit -- It seems I didn't express myself too clearly. I am not so concerned about the validation. I am more concerned about where the creation logic code should go :

假设控制器上的操作称为支出，当使用支出时，参数散列将包含:金额、日期、描述.借方和贷方帐户将从被调用的操作派生，但随后我必须创建所有对象.最好有

assuming the operation on the controller is called spend, when using spend, the params hash would contain : amount, date, description. Debit and credit accounts would be derived from the action which is called, but then I have to create all the objects. Would it be better to have

#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

或者在 Operation 上创建一个方法，使上面看起来像

or to create a method on Operation that would make the above look like

def spend
  op=Operation.new_simple_operation(params)
  op.save
end

这肯定会提供一个更薄的控制器和一个更胖的模型，但是模型将创建和存储其他模型的实例，这就是我的问题所在.

this definitely give a much thinner controller and a fatter model, but then the model will create and store instances of other models which is where my problem is.

推荐答案

但是模型将创建和存储其他模型的实例，这就是我的问题所在.

but then the model will create and store instances of other models which is where my problem is.

这有什么问题吗?

如果您的业务逻辑"声明一个操作必须具有一组有效的条目，那么对于操作类来说，了解和处理您的条目对象肯定没有错.

If your 'business logic' states that an Operation must have a valid set of Entries, then surely there is nothing wrong for the Operation class to know about, and deal with your Entry objects.

如果你走得太远，你只会遇到问题，并且让你的模型处理他们不需要知道的东西，比如 EntryHtmlFormBuilder 或其他任何东西:-)

You'll only get problems if you take this too far, and have your models manipulating things they don't need to know about, like an EntryHtmlFormBuilder or whatever :-)

这篇关于为了瘦控制器，rails 模型应该关注其他模型吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！