Я работаю над повторной записью моего приложения на основе того, что я узнал на RailsConf 2009. Я понимаю, что Model, Controller и View связаны друг с другом. Однако одна вещь, с которой я боролся, - это «правильный» уровень для контроллера.Rails и метафоры MVC
Если карты Rails модели (примерно) в таблице БД ... И если Rails Просмотр карты (примерно) на странице браузера ...
Что делает карту Rails контроллер для?
Контроллер - это средство подключения моделей (моделей) к виду (-ам) с использованием логики, ограничений и условий вашего решения.
Итак, я полагаю, это могло бы быть связано с «мозгами» вашего решения.
Контроллер действительно не сопоставляется ни с чем в контексте, который вы ищете. Вы должны думать о контроллере как клее, который вы используете для размещения модели с представлением.
Модель излагает ваши данные.
The View отображает представление данных.
Контроллер отвечает за принятие запроса и возврат надлежащей модели и просмотра ... затем представление этого результата пользователю.
Если вы ищете метафора MVC один, который помог мне получить вещи немного легче, когда начинал я думал о вещах, как это:
Модель - Ваш скелет (Помогает структуры вещей)
контроллер - Ваши мышцы (Помогает все двигаться и делать необходимые задачи)
Просмотр - Ваш Внешний вид (Это, как мир видит, что делают две другие части)
Это самый простой способ, которым я мог придумать себе, чтобы заставить себя «получить его», надеюсь, это помогает. Опять же, элемент управления в этой части «отобразит» все, что работает для ваших приложений.
Все хотят сравнить его с клеем или мышцей или чем-то еще, но это плохо подходит для любого из них, потому что это переводчик между моделью и видом. Мышцы не служат входной функции, только выход, нервы и чувства обеспечивают вход в эту аналогию. Клей просто придерживается двух вещей вместе, это не меняет их.
Уровень контроллера в MVC отвечает за вывод данных из модели и перевод ее в форму, готовую для просмотра, чтобы отображать ее. Прекрасным примером этого являются три разные страницы, все представленные данные в той же (или очень похожей) форме, но отображаемые данные поступают из самых разных источников. В каждом из этих случаев может использоваться один и тот же код представления, однако контроллер - тот, кто знает, чтобы вызывать разные функции в модели, чтобы отобразить данные и поместить их в нужное имя коллекции, чтобы представление могло находить и отображать он, , хотя представление фактически не знает, что он отображает.
Но это не единственная задача для уровня контроллера, поскольку он также должен выполнять перевод запросов пользователя в действия над моделью. Пользователь щелкнул ссылку или набрал что-то в поле или сдвинул ползунок, и это может привести к одному или нескольким действиям модели. Это не должно быть фактической бизнес-логикой принятия решений, но если, например, у вас был флажок, который сказал «делать это три раза», но у модели была функция только что-то сделать один раз, контроллер будет отвечать за вызов функции модели три чтобы выполнить действие.
Если у вас есть аналогия, я бы использовал ответ Майкла «мозги».
«Ответственный за извлечение данных из модели», что делает DAO или является частью уровня контроллера? –
Контролер является менеджером или координатором. Подумайте о моделях и представлениях как о двух разных группах внутри компании (возможно, о продажах и ИТ). Контроллер - это человек, который сидит над этими двумя и уверен, что они хорошо играют вместе.
Сказав это, все эти метафоры будут некорректными. Например, контроллер обычно гарантирует, что пользователь зашел на страницы, на которых пользователь должен войти в систему. Это действительно не соответствует моей метафоре или некоторым другим.
Контроллер сопоставляется с URL-адресом, особенно при использовании RESTFUL-ресурсов.
Мне нравится думать о URL-адресе как интерфейсе командной строки для вашего приложения.
Я думаю, что это бедная метафора. Модель должна выполнять необходимые задачи. Контроллер более сродни скелету ИМХО. –