Модель направляющих, Представление, Контроллер и Помощник: что идет где?

Добавить к ответу pauliephonic:

Помощник : функции для создания создания представления легче. Например, если Вы всегда выполняете итерации по списку виджетов для отображения их цены, поместите ее в помощника (наряду с частичным для фактического дисплея). Или если у Вас есть часть RJS, что Вы не хотите загромождать представление, помещаете его в помощника.

Шаблон MVC действительно только касается UI и ничего иного. Вы не должны помещать сложную бизнес-логику в контроллер, поскольку это управляет представлением, но не логикой. Контроллер должен интересоваться выбором надлежащего представления и делегировать более сложный материал к модели предметной области (Модель) или бизнес-слой.

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

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

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

Направляющие путь должны иметь тощие контроллеры и толстые модели .

Действительно поместите материал, связанный с авторизацией/управлением доступом в контроллере.

Модели - все о Ваших данных. Проверка, Отношения, CRUD, Бизнес-логика

Представления о показе Ваших данных. Дисплей и быть введенным только.

Контроллеры об управлении, какие данные идут от Вашей модели до Вашего представления (и которые просматривают), и от Вашего представления до Вашей модели. Контроллеры могут также существовать без моделей.

мне нравится думать о контроллере как охраннику / регистратор, который направляет Вас клиент (запрос) к соответствующему счетчику, где Вы задаете кассиру (представление) вопрос. Кассир (представление) тогда идет и получает ответ от менеджера (модель), кого Вы никогда не видите. Вы запрос тогда возвращается к охраннику / регистратор (контроллер) и ожидает, пока Вы не предписаны пойти другой кассир (представление), кто говорит Вам ответ, менеджер (модель) сказал им в ответ на другого кассира (представление) вопрос.

Аналогично, если Вы хотите сказать кассиру (представление) что-то тогда в основном, то же самое происходит кроме второго кассира, скажет Вам, принял ли менеджер Вашу информацию. Также возможно, что охранник / регистратор (контроллер), возможно, сказал Вам брать экскурсию, так как Вы не были разрешены сказать менеджеру ту информацию.

Так для расширения метафоры, в моем стереотипном и нереалистичном мире, кассиры (представления) симпатичны, но легкомысленны и часто верят чему-либо, что Вы говорите им, охранник / регистраторы минимально вежливы, но не очень хорошо осведомлены, но они знают, где люди должны и не должны идти, и менеджеры действительно уродливы и имеют в виду, но знают все и могут сказать то, что верно и что не.

Одна вещь, которая помогает отделиться правильно, избегает "локальных переменных передачи от контроллера для просмотра" антишаблона. Вместо этого:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

Попытка, перемещающая его к методу get, который доступен как вспомогательный метод:

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

Это облегчает изменять то, что вставляется в "@foo" и как он используется. Это увеличивает разделение между контроллером и представлением, не делая их больше сложными.

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

j

Ну, это, вид зависит от того, с чем должна иметь дело логика...

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

кроме того, быстрый бит Google показывает несколько более конкретных примеров того, что идет где.

Модель: требования проверки, отношения данных, создают методы, обновляют методы, уничтожают методы, находят методы (обратите внимание, что у Вас должны быть не только универсальные версии этих методов, но и если существует что-то, что Вы делаете много, как нахождение людей с рыжими волосами фамилией, тогда необходимо извлечь ту логику так, чтобы все, что необходимо сделать, было назвать find_redH_by_name ("кузнец") или что-то как этот)

Представление: Это должно быть всеми о форматировании данных, не обработке данных.

Контроллер: Это - то, куда обработка данных идет. Из Интернета: "controller’s цель состоит в том, чтобы ответить на действие, которое требует пользователь, взять любые параметры, пользователь установил, обрабатывает данные, взаимодействует с моделью, и затем передает запрошенные данные, в конечной форме, прочь к представлению".

Hope, которая помогает.