Рисование линии между моделью и контроллером

Question

Я создаю это спокойное приложение, используя RoR, и мне немного трудно провести грань между вещами, которые должны идти в модели, и вещами, которые должны идти в контроллере.

В качестве примера, у меня есть 7 методов на контроллере (те, которые делают его спокойным, то есть index (), show (), create (), update () ...) и часто считают, что необходимо добавить дополнительные методы, создавая их как члены.

Что я хотел бы сделать здесь, так это собрать от вас опыт, ребята, что и где происходит (то есть я должен прикрепить все взаимодействия с базой данных на модели и просто вызвать эти методы из контроллера?)

Кроме того, добавляя вещи, которые не связаны с БД, в мой контроллер, т.е. я хочу сделать HTTP-вызов для скрининга некоторых данных с веб-сайта.

HTTP-звонки могут стать большими и грязными. Должно ли все это идти на мой контроллер, или это должен быть отдельный класс или модуль, и должно быть включено только в мой контроллер, чтобы его можно было вызывать?

Если это так, какой наилучший способ сделать это?

Я немного запутался со всем этим, так что было бы здорово получить чей-то вклад.

Заранее спасибо

Answer 1

Он является частью Домен-управляемый дизайн .

Домен - это область знаний, которая определяет область, с которой приложение пытается работать и решать проблемы.

Слой модели считается слоем домена. Именно здесь соблюдаются все правила, которые определяют домен или бизнес-логику. Модель действует как фильтр между реальными данными и остальной частью приложения таким образом, что определяет домен.

Детали реализации Домена (mySQL или MSSql или файл Webservice или Xml, или внешняя веб-страница или что-либо другое) скрыты Моделью.

Контроллер - это просто посланник. Его задача - принимать сообщения от пользователя и передавать их в модель. Модель приходит с ответом, и контроллер разрабатывает лучший способ передать это пользователю.

Вид похож на визажиста, просто следя за тем, чтобы данные выглядели хорошо и презентабельно для пользователя.

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

Answer 2

Вообще говоря, хорошим подходом (без религиозного пламени, плз) является наличие тонких контроллеров и толстых моделей. Таким образом, вы также можете легко тестировать «вещи», которые должны делать модели ...

Answer 3

придерживаюсь правил тонких контроллеров и жирных моделей.

При спокойном подходе я держу все контроллеры в соответствии с этим стандартом, и у меня больше нет методов, кроме стандартных. Если мне требуются новые функциональные возможности и я отмечаю, что методы выполняют схожие вещи (или имеют похожее имя, например, group_add, group_remove), я создаю новый контроллер и использую существующие модели и создаю новые методы в модели.

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

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

Answer 4

Соскреб должен выполняться в модели, отличной от ActiveRecord, и контроллер должен просто вызывать методы этой модели.

Существует хороший пример модели AR без таблицы и one модели без AR на railscasts .

Итак, ваш контроллер будет делать что-то вроде:

def index
  @some_things = SomeThing.all
end

def show
  @some_thing = SomeThing.find params[......]
end

И ваша SomeThing модель будет реализовывать необходимую логику.

Answer 5

Я также предпочитаю тощие контроллеры и толстые модели ... Хорошим инструментом, который поможет вам обеспечить соблюдение этого правила, является камень наследованный_ресурсы от Хосе Валима. Я предлагаю вам взглянуть на это: http://github.com/josevalim/inherited_resources

Answer 6

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

Если вы сомневаетесь, думайте о вашей модели как о приложении и о вашем представлении / контроллере как о интерфейсе. Если его интерфейс не совсем понятен, он, вероятно, принадлежит модели.

Этот вопрос может помочь.