这种类型的计算是放在Model还是Controller中？答案

【问题标题】：Is this type of calculation to be put in Model or Controller?这种类型的计算是放在Model还是Controller中？
【发布时间】：2010-06-01 10:10:31
【问题描述】：

我有 Product 和 SalesOrder 模型（为了简化，1 个 sales_order 仅适用于 1 个产品）

Product
 has_many :sales_orders

SalesOrder
 belongs_to :product

pa = Product A #2000
so1 = SalesOrder #1 order product A #1000, date:yesterday
so2 = SalesOrder #2 order product A #999,  date:yesterday
so3 = SalesOrder #3 order product A #1000, date:now

根据日期，pa.find_sales_orders_that_can_be_delivered 将给出：

SalesOrder #1 order product A #1000, date:yesterday
SalesOrder #2 order product A #999,  date:yesterday
SalesOrder #3 order product A #1,    date:now <-- the newest

问题是：find_sales_orders_that_can_be_delivered 应该在模型中吗？我可以在控制器中做到这一点。

一般的问题是：什么在模型中，什么在控制器中。

谢谢

【问题讨论】：

你能稍微格式化一下你的代码吗？
当然，抱歉给您带来了麻烦。

标签： ruby-on-rails ruby model controller

【解决方案1】：

很简单：

微型控制器，胖模型

你在你的模型中创造了一切。如果你把你的控制器放进去，你就不能在不同的部分重复使用它。

耙任务
其他控制器
控制台

所以把所有可能的都放在你的模型中。在控制器中，您只使用会话/cookie 进行操作。重定向部分和使用哪个视图。

【讨论】：

【解决方案2】：

我认为这个逻辑应该交给模型，因为这与对象的属性有关。

对于一般性问题的解决方案 - 您可以在这里阅读：http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

【讨论】：

【解决方案3】：

当然，请将此逻辑排除在控制器之外。控制器应该将业务决策交给模型。这就是拥有 MVC 框架的全部意义所在。

此外，我会将逻辑放在 SalesOrder 上，而不是 Product 上——它看起来很适合 named_scope。也许是这样的（请记住，我不知道您计算可交付订单日期的具体规则是什么）：

named_scope :deliverable, lambda {{ :conditions => ["date < ?", Date.today] }}

使用 lambda 封装可确保使用当前日期值实时评估 :conditions。显然 :conditions 取决于您对可交付订单的业务规则，但您明白了。这将允许一个很好的方法链，如：

pa.sales_orders.deliverable

现在您可以在任何有 has_many :sales_orders 的地方重复使用该逻辑。

【讨论】：

named_scope 看起来不错，但我怀疑它是否可行，因为交付物需要查看整个数据库，比较产品库存（并实际上降低其价值），因为发现一个销售订单具有所需物品。好吧，为了简单起见，它需要在销售订单中分配变量，可以交付多少这样的产品。我希望你明白我的意思。

【解决方案4】：

Here's a nice article 在 Rails 中的 MVC 模式上。总结一下：控制器应该是瘦的，模型应该是胖的;-)

【讨论】：

【解决方案5】：

我认为这应该在模型中。通常，当我想决定控制器或模型中是否有某些东西时，我会问自己“如果我以其他方式访问数据，我想要这个吗？”。

例如，如果数据正被另一个控制器（例如管理工具）访问，我还想使用该功能吗？我还需要它吗？那么它与模型有关，而不是控制器。

另一个例子：如果数据正在被另一个应用程序（例如桌面应用程序）访问，我还需要这个功能吗？和以前一样。

【讨论】：