Модель Rails, View, Controller и Helper: что происходит?

Ответ 1

MVC

Контроллер. Поместите здесь код, который связан с разработкой того, что хочет пользователь, и решите, что им дать, чтобы выяснить, вошли ли они в систему, должны ли они видеть определенные данные и т.д.. В конце концов, контроллер просматривает запросы и разрабатывает, какие данные (Модели) показывать и какие представления для рендеринга. Если вы сомневаетесь в том, должен ли код идти в контроллер, то, вероятно, этого не произойдет. Храните ваши контроллеры skinny.

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

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

Ответ 2

Чтобы добавить к pauliephonic ответ:

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

Ответ 3

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

Domain Driven Design имеет концепцию сервисов, которая является местом, в которое вы вставляете логику, которая должна настраивать несколько различных типов объектов, что обычно означает логику, которая, естественно, не принадлежит классу модели.

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

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

Ответ 4

Идеальные объяснения здесь уже, одно очень простое предложение как заключение и легко запоминающееся:

Нам нужны SMART-модели, THIN-контроллеры и DUMB-представления.

http://c2.com/cgi/wiki?ModelViewController

Ответ 5

Путь Rails должен состоять из тощих контроллеров и толстых моделей.

Ответ 6

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

Модели - все о ваших данных. Валидация, отношения, CRUD, бизнес-логика

Представления касаются отображения ваших данных. Отображать и получать только вход.

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

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

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

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

Ответ 7

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

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

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

end

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

Попробуйте переместить его в getter, который доступен как вспомогательный метод:

# 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" и как оно используется. Это увеличивает расстояние между контроллером и видом, не делая их более сложными.

Ответ 8

Ну, это зависит от того, с чем логика справляется...

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

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

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

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

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

Надеюсь, что это поможет.

Ответ 9

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

Контроллеры будут иметь код/​​указатели для соответствующих моделей для запрошенной работы.

Представления будет принимать пользовательский ввод/взаимодействие и отображать результирующий ответ.

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

Ответ 10

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

J