Этот тип расчета должен быть помещен в модель или контроллер?

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 быть в модели? я могу сделать это в контроллере.

и общий вопрос: что входит в модель, а что в контроллер.

Спасибо

Answer 1

Все просто:

Tiny Controller, Жир Модель

Вы сделали все в своей модели. Если вы вставите свой контроллер, вы не сможете использовать его в другой части.

• Рейк-задание
• Другой контроллер
• Консоль

Так что вложите все возможное в вашу модель. В Controller вы кладете только манипуляции с сессией / cookie. Часть перенаправления и какое представление используется.

Answer 2

Я думаю, что эта логика должна идти в Model, поскольку это связано со свойствами объектов.

Для решения обобщенной проблемы - вы можете прочитать здесь: http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model

Answer 3

Абсолютно, держите эту логику вне контроллера. Контролеры должны передавать бизнес-решения моделям. Это весь смысл наличия MVC фреймворка для начала.

Кроме того, я бы поставил логику в SalesOrder, а не в Product - это выглядит как хороший кандидат для named_scope. Может быть, что-то вроде этого (и, имея в виду, я не знаю, каково ваше конкретное правило для расчета даты доставки заказа):

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

Обтекание лямбдой гарантирует, что: условия будут оцениваться в режиме реального времени, используя текущее значение даты. Очевидно, что условия зависят от того, какое правило вашего бизнеса применяется для доставляемых заказов, но вы поняли идею. Это позволило бы создать хорошую цепочку методов, например:

pa.sales_orders.deliverable

Теперь вы можете повторно использовать эту логику везде, где есть has_many: sales_orders.

Answer 4

Вот хорошая статья о шаблоне MVC в Rails. Подводя итог: контроллеры должны быть худыми, а модели жирными; -)

Answer 5

Я думаю, что это должно быть в модели. Обычно, когда я хочу решить, идет ли что-то в контроллере или модели, я спрашиваю себя: «Хочу ли я этого, если получу доступ к данным другим способом?».

Например, если к данным обращается другой контроллер, например, инструмент администратора, я все еще хочу использовать эту функцию? Мне все еще нужно это? Тогда это относится к модели, а не к контроллеру.

Другой пример: если к данным обращается другое приложение, например, настольное приложение, мне все еще нужна эта функциональность? То же, что и раньше.