Question

我有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应该在模型中吗？我可以在控制器中完成。

，一般的问题是：模型中的内容以及Controller中的内容。

谢谢

Answer 1

很简单：

Tiny Controller，Fat Model

你在你的模特中做了所有。如果您放入控制器，则无法在不同的部分重复使用它。

佣金任务
其他控制器
控制台

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

Answer 2

我认为这个逻辑应该转到Model，因为这与对象的属性有关。

对于广义问题的解决方案 - 您可以在此处阅读：http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

Answer 3

关于Rails中MVC模式的

Here's a nice article。总结一下：控制器应该是精益的，模型很胖; - ）

Answer 4

当然，将此逻辑保留在控制器之外。控制器应将业务决策交给模型。这是开始使用MVC框架的全部要点。

此外，我将逻辑放在SalesOrder上，而不是产品 - 它看起来像是一个适合named_scope的人选。也许这样的事情（记住我不知道你的具体规则是什么，用于计算可交付订单的日期）：

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

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

pa.sales_orders.deliverable

现在，只要有has_many：sales_orders，就可以重复使用该逻辑。

Answer 5

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

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

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

这种类型的计算是放在模型还是控制器中？

5 个答案: