Все ли мои компоненты MVC действительно нуждаются в ссылках друг на друга?
Я играю с MVC в PHP. Я не использую рамки, я просто пытаюсь понять шаблон.
Иногда я вижу контроллеры, например, в этом уроке, которые создаются с помощью моделей и представлений, переданных в конструктор, и в том же уроке класс view (здесь "Template") принимает Controller в конструкторе!
Итак, мой вопрос:
- Почему представление может ссылаться на свой контроллер? Не должно ли мнение быть пассивным партнером в этих отношениях?
- Должен ли контроллер иметь внутреннюю ссылку на конкретную модель? Или, другими словами, почему бы просто не создавать экземпляры моделей в действиях контроллера и использовать их таким образом?
5 ответов
Если у вас есть пользовательские входы, вам нужно знать, куда их отправлять.. на какой контроллер.
Мне не нравится, когда мои контроллеры играют с моделями напрямую, потому что контроллеры подвержены "внешнему миру" и подвержены атакам. Вы можете взглянуть на шаблон уровня сервиса, шаблон объекта передачи данных и т. Д. Мне нравится, когда мои модели изолированы от API сервиса, который будут использовать контроллеры. Если вам нужна хорошая книга о шаблонах, вы можете найти книгу Мартина Фаулера:)
Учитывая множество вариантов и неправильных представлений о MVC в Интернете, я проголосовал за то, чтобы закрыть вопрос как неконструктивный. Я предоставляю этот ответ в виде вики сообщества из-за ограниченного размера комментариев.
Первоначально MVC был задуман Trygve Reenskaug для настольных сред, а не для Интернета. В настоящее время мы видим в основном вариации исходного шаблона в той или иной форме, например, MVP, HMVC, Model2-MVC и так далее. Их реализации отличаются друг от друга, и люди потратили много времени на размышления о том, что такое "MVC" на самом деле или как его следует реализовывать.
Лично я предпочитаю определение MVC " Шаблоны корпоративной прикладной архитектуры", в котором говорится, что MVC разделяет взаимодействие с пользовательским интерфейсом на три разные роли, поскольку в этом определении нет понятия реализации.
В книге Фаулер отмечает, что наиболее важным отличием является отделение Модели от Контроллера и Представления. Хотя книга охватывает связи между ролями, чтобы донести этот аргумент, я думаю, что главное - понять и сосредоточиться на ролях, а не на реализации.
Шаблоны проектирования - это чертежи, а не подробные схемы. Кроме того, MVC является языком шаблонов. Его цель - добавить структуру / форму в проект. Поймите, для чего нужны роли, а затем придумайте реализацию, которая работает в вашем проекте.
У Фаулера также есть длинная статья об архитектурах GUI, в которой рассказывается о MVC, в которой подробно объясняются связи и зависимости на случай, если у вас нет книги под рукой.
Изображения / слайды из: Архитектура потерянных лет (Роберт Сесил Мартин; 4 ноября 2011)
По моему опыту, существует много толкований того, что именно означает MVC. Почти все согласны с тем, что в целом:
- Модели реализуют бизнес-логику и обеспечивают доступ к данным.
- Представления реализуют логику представления.
- Контроллеры обрабатывают ввод и управляют потоком.
То, как они общаются и разговаривают друг с другом, является предметом споров, споров, кулачных боев и священных войн.
На практике контроллеры обычно загружают представления и модели, представления иногда загружают модели и контроллеры, но модели обычно не загружают контроллеры или представления.
Почему представление загружает контроллер? Допустим, вы реализовали виджет, который имеет собственный контроллер, модель и вид. Вы хотите загрузить этот виджет на нескольких страницах в нескольких местах. Самый простой способ сделать это - загрузить контроллер виджета в виде.
Почему представление загружает модель? Возможно, вы написали свой контроллер, чтобы он мог загружать два или более представления, и вам не нужно загружать разные модели для каждого из самых разных представлений. Таким образом, вы просто указываете каждому представлению загружать свои собственные модели.
Разделите роли, но учтите, какое взаимодействие наиболее эффективно и логически реализует систему, в которой вы нуждаетесь.
Поскольку мне уже удалось подробно написать о модели в контексте MVC и PHP, давайте сосредоточимся View а также Controller части триады.
Как @Gordon уже упоминал, что то, что мы делаем в Сети, не является классическим MVC. Это не возможно ралли. Вместо этого мы предложили различные варианты оригинальной идеи.
Вид не шаблон
Если вы не используете особенно плохую реализацию MVP, view экземпляры - это объекты, отвечающие за логику представления.
Будь то controller Экземпляр нуждается в доступе к view зависит от того, какой паттерн в стиле MVC вы используете. В шаблонах MVP и MVVM controller экземпляр запрашивает информацию от model layer и передает его view (либо с некоторыми изменениями, либо с дополнительными флагами).
В модели Model2 (которая несколько ближе к оригинальной концепции), view Сам экземпляр способен извлекать информацию из model layer, В этом случае нет необходимости controller экземпляр, чтобы иметь доступ к нему.
За что отвечает контроллер?
Экземпляры controller не должны быть непосредственно экземплярами структур из model layer, Для этого есть две основные причины:
- вызывает тесную связь с конкретными именами классов, усложняет тестирование и обслуживание
- добавляет дополнительную ответственность (или причину для изменения) и тем самым - нарушает SRP
Инициализация структур из model layer это сложно. Обычно они требуют, чтобы вы внедрили соединение с базой данных, обработчики кэша или даже другие структуры из model layer, Эта задача должна быть оставлена отдельному фабричному экземпляру (совместно используемому controller а также view экземпляры), который использует контроллер.
Основная ответственность controller Экземпляр должен изменить состояние model layer, Он должен принять ввод от пользователя и перевести его в форму, понятную для model layer,
Имейте в виду, что model layer в целом должно быть совершенно неосведомлен о view а также controller экземпляров.
Представление не должно ссылаться на контроллер (кроме ссылок действий, конечно). Контроллер выполняет действие, которое ему говорят, и отправляет результат в представление.
Насколько я использовал MVC, я создаю модель в действии и использую ее таким образом. Мне не нравится, когда мои контроллеры привязаны к моделям. Обычно я использую структуру хранилища для доступа к моим моделям. В более крупных проектах у меня есть сервисный уровень между контроллерами и моделями. В.net MVC я начал играть с использованием viewmodels в качестве объекта, на который смотрят контроллеры и часть приложения MVC, в то время как мои сервисы обрабатывают все, что связано с моими моделями доменов, и возвращают viewmodels.