这种类型的计算是放在模型还是控制器中？
我有 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 应该在模型中吗？ 我可以在控制器中做到这一点。
一般的问题是：模型中包含什么，控制器中包含什么。
谢谢
i have Product and SalesOrder model (to simplify, 1 sales_order only for 1 product)
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
Based on the date, pa.find_sales_orders_that_can_be_delivered will give:
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
The question is: is find_sales_orders_that_can_be_delivered should be in the Model?
i can do it in controller.
and the general question is: what goes in Model and what goes in Controller.
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
很简单：
您在模型中完成了所有操作。如果您放入控制器，则无法在不同部分重复使用它。
因此，将所有可能的内容放入您的模型中。在控制器中，您仅使用会话/cookie 进行操作。重定向部分以及使用哪个视图。
It's simple :
You made all in your model. If you put in your controller you can't reuse it in different part.
So put all possible in your model. In Controller you put only manipulation with session/cookie. The redirect part and which view is use.
我认为这个逻辑应该进入模型，因为这与对象的属性相关。
对于一般性问题的解决方案 - 您可能想在这里阅读：http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
I think this logic should go to Model as this is related to objects' properties.
For solution to generalized problem- you may like to read it up here : http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model
当然，请将此逻辑排除在控制器之外。控制者应该将业务决策交给模型。这就是 MVC 框架的全部意义所在。
此外，我将逻辑放在 SalesOrder 上，而不是 Product 上——它看起来是named_scope 的一个很好的候选者。也许是这样的（请记住，我不知道计算可交付订单的日期的具体规则是什么）：
用 lambda 包装可确保使用当前日期值实时评估：条件。显然，:条件取决于您的可交付订单的业务规则，但您明白了。这将允许一个很好的方法链，例如：
现在，只要有 has_many :sales_orders，您就可以重复使用该逻辑。
Absolutely, keep this logic out of the controller. Controllers should hand off business decisions to the models. This is the entire point of having an MVC framework to begin with.
Additionally, I'd put the logic on SalesOrder, not Product -- it looks like a good candidate for a named_scope. Maybe something like this (and keeping in mind I have no idea what your specific rule is for calculating the date of of a deliverable order):
Wrapping with a lambda makes sure the :conditions are evaluated in real time, using the current date value. Obviously the :conditions are dependent on whatever your business rule is for deliverable orders, but you get the idea. This would allow a nice method chain like:
Now you can re-use that logic wherever there's a has_many :sales_orders.
这是一篇关于 MVC 模式的好文章导轨。总结一下：控制器应该瘦，模型应该胖;-)
Here's a nice article on the MVC pattern in Rails. To sum up: controllers should be lean, and models fat ;-)
我认为这应该在模型中。通常，当我想要决定某些内容是否进入控制器或模型时，我会问自己“如果我以其他方式访问数据，我是否想要这个？”。
例如，如果数据正在由另一个控制器（例如管理工具）访问，我是否仍然想使用该功能？我还需要它吗？那么就和模型有关，而不是控制器。
另一个例子：如果数据正在被另一个应用程序（例如桌面应用程序）访问，我是否仍然需要此功能？和以前一样。
I think this should be in the model. Generally when I want to decide whether something goes in the controller or the model I ask myself "Do I want this if I access the data in another way?".
For example, if the data is being accessed by another controller, like an admin tool, do I still want to use that functionality? Would I still need it? Then it is related to the model, not the controller.
Another example: if the data is being accessed by another app, a desktop app for example, would I still want this functionality? Same as before.