Разграничивание между моделью и Контроллером
Я создаю это успокоительное использование приложения RoR и нахожу немного трудным чертить линию между вещами, которые должны пойти на модель и вещи, которые должны пойти на контроллер.
Как пример, у меня есть 7 методов на моем контроллере (те, которые делают его успокоительным т.е. индекс (), показывают (), создают (), обновление ()...), и часто находите, что это необходимо добавить дополнительные методы и делает так путем создания их как участников.
То, что я хотел бы выполнить здесь, собирают опыт от Вас парни на том, что идет, где (т.е. я должен прикрепить все взаимодействия базы данных на модель и просто назвать те методы от контроллера?)
Кроме того, путем добавления вещей, которые не включают DB к моему контроллеру т.е. Я хочу сделать HTTP-вызов экранного царапанья некоторыми данными из веб-сайта.
HTTP-вызовы могут стать большими и грязными. Все это должно перейти к моему контроллеру, или это должно пойти отдельный класс или модуль, и только быть включено в мой контроллер, таким образом, это можно назвать?
Если так, каков был бы лучший подход, чтобы сделать это?
Я немного перепутан со всем этим, таким образом, было бы замечательно иметь чей-то вход.
Заранее спасибо
6 ответов
Это часть Domain Driven Design.
Домен - это сфера знаний, определяющая область, с которой приложение пытается работать и решать проблемы.
Уровень модели считается уровнем домена. Именно здесь хранятся все правила, определяющие Домен или бизнес-логику. Модель действует как фильтр между реальными данными и остальной частью приложения таким образом, что определяет домен.
Детали реализации Домена (mySQL или MSSql или Webservice или Xml файл или внешняя веб-страница или что-либо еще) скрыты Моделью.
Контроллер - это просто посыльный. Его задача - принимать сообщения от пользователя и передавать их Модели. Модель приходит с ответом, а контроллер разрабатывает лучший способ передать его пользователю.
Представление - это как визажист, который следит за тем, чтобы данные выглядели хорошо и презентабельно для пользователя.
Сайт, который вы соскабливаете, можно считать частью домена. Этот сайт содержит знания, определяющие мир, который определяет ваше приложение. Процесс скрейпинга - это создание этих знаний таким образом, чтобы они соотносились с остальной картиной мира, которую определяет ваше приложение. Контроллеру неважно, откуда взялись эти знания, он просто передаст их представлению. Представление обработает данные, сделает их красивыми и отправит их пользователю, который совершенно не замечает всего этого процесса и просто видит красивую веб-страницу!
Когда я использовал вызовы SOAP из Rails, что в некотором смысле похоже на то, о чем вы говорите, я рассматривал их как источник данных, так что, на мой взгляд, они принадлежали модели. Вы также можете выбрать, если функциональность несколько универсальна, написать плагин, который также выполняет эту работу, или найти плагин, который уже делает большую часть того, что вы хотите, и использовать это.
Если есть сомнения, подумайте о вашей модели как о приложении, а о вашем представлении / контроллере как об интерфейсе. Если его нечеткий интерфейс, он, вероятно, принадлежит к модели.
Я также предпочитаю тонкие контроллеры и толстые модели ... Хорошим инструментом, который поможет вам обеспечить соблюдение этого правила, является жемчужина inherited_resources Хосе Валим. Предлагаю вам взглянуть на это: http://github.com/josevalim/inherited_resources
Материал для скраппинга должен находиться в модели, не относящейся к ActiveRecord, а контроллер должен просто вызывать методы этой модели.
Есть хороший пример AR-модели без таблиц и пример не AR-модели на railscasts.
Итак, ваш контроллер будет делать что-то вроде:
def index
@some_things = SomeThing.all
end
def show
@some_thing = SomeThing.find params[......]
end
А ваша модель SomeThing будет реализовывать необходимую логику.
Вообще говоря, хороший подход (без религиозного флейма, plz) - это иметь тонкие контроллеры и толстые модели. Таким образом, вы также сможете легко протестировать "вещи", которые должны делать модели...
Я придерживаюсь правил тонких контроллеров и толстых моделей.
При спокойном подходе я поддерживаю все контроллеры в соответствии с этим стандартом и не имею в них никаких других методов, кроме стандартных. Если мне требуются новые функции и я отмечаю, что методы делают похожие вещи (или будут иметь похожее название, например group_add, group_remove), я создаю новый контроллер, использую существующие модели и создаю новые методы в модели.
Это также позволяет осмысленно подходить к этим дальнейшим действиям, и, в частности, каждое действие имеет узко определенные характеристики для своей операции, оно никогда не будет делать больше одного действия. Нет ничего хуже, чем использование вызова API, который делает две вещи в зависимости от того, как он вызван.
Подход, который я использую, заключается в том, чтобы обрабатывать запрос как можно быстрее, используя как можно меньше кода и абстрагируя сложные задачи / операции от модели.