Изучение основных направлений: где поставить условную бизнес-логику? - PullRequest
Новая
       7

Изучение основных направлений: где поставить условную бизнес-логику?

1 голос
/ 14 июля 2011

Так что я пытаюсь научить себя рельсам, и у меня возникают проблемы с выяснением, куда идет логика.В моем упражнении у меня есть модель оплаты.class pyament Integer Product_Type String Product_name

Существуют правила для обработки платежей, если product_Type является физическим, делайте это, если виртуальный, делайте это, если product_name - book, делайте это, если product_name - корова, делайте это

То, что я не могу понять, - это где поставить эти правила.Я делаю метод в модели, называемой процессом, который выполняет эти правила?Это логика идет в контроллере?Мне просто непонятно.

Любое понимание будет оценено.

Спасибо

Ответы [ 3 ]

6 голосов
/ 14 июля 2011

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

См .: http://joemcglynn.wordpress.com/2009/12/11/rails-sti-part-1/http://joemcglynn.wordpress.com/2009/12/12/rails-single-table-inheritance-part-2/

По сути, идея такова: вы уже определяете тип продукта - столбец «тип» является основной функцией таблицы STI.

С STI вместо одногоВ модели с тоннами условной логики или несколькими моделями у вас есть несколько ОЧЕНЬ ПОДОБНЫХ моделей с ОЧЕНЬ ПОДОБНЫМИ данными, но несколько отличной логикой, поэтому все эти связанные модели могут использовать одну и ту же таблицу и наследовать от общего класса.

Например: 

class Product < ActiveRecord::Base
  ...
  common logic goes here
  ...
end

class PhysicalProduct < Product
  ...
  physical-product-specific logic goes here
  ...
end

class VirtualProduct < Product
  ...
  virtual-product-specific logic goes here
  ...
end

Таким образом, вы можете создать метод, подобный product.deliver, который определен по умолчанию в модели продукта, чтобы инициировать доставку продукта, но в модели VirtualProduct переопределяетсявместо этого инициировать отправку по электронной почте ссылки на скачивание.

ActiveRecord обрабатывает все это очень хорошо (см.выше, для ознакомления), и большинство ваших форм, ссылок, контроллеров и т. д. будут продолжать работать так же, как в настоящее время.

В общем, вы всегда хотите сохранить столько логики, скольковозможно в моделях вместо контроллеров, потому что модели легче тестировать и легче отлаживать. В вашей ситуации STI - хороший способ сохранить эту логику ветвления в моделях вне контроллеров и представлений.

4 голосов
/ 14 июля 2011

Для начала, этот список является хорошей отправной точкой .

Я согласен, что правила манипулирования данными / бизнес-правила лучше всего подходят для модели.Содержите представления и контроллеры в чистоте, чтобы ваша модель могла содержать все структуры хранения и логические правила.

2 голосов
/ 14 июля 2011

Как правило, вы хотите, чтобы ваша бизнес-логика в моделях. «Fat Model, Skinny Controller» - это классная фраза Rails, используемая для описания этого. См. post для получения дополнительной информации, и не обращайте внимания на устаревший синтаксис Rails.

...