Вопрос о лучшей практике MVC

Question

У меня есть вопрос относительно дизайна MVC, основанного на лекциях Стэнфордского iPhone.

У меня есть 3 класса;

Полигон - он содержит информацию, такую ​​как количество сторон и так далее.Это мой класс модели

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

Представление - для этого вопроса представлением будет класс, представляющий отдельное представление, которое рисует многоугольник на экране.

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

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

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

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

Спасибо!

Answer 1

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

Что касается представления , а не , это контекст,«История жизни» отображаемого объекта.Это может происходить из сети, оно может скоро измениться, оно может стать в два раза больше при нажатии на него.Вид не волнует.Если вы щелкните по нему, представление может сообщить о событии обратно контроллеру и больше не будет о нем заботиться.Если объект изменяется, контроллер сообщит представлению обновить.

Я не думаю, что есть жесткое правило для разработки таких отношений, но суть проста: держите слабую связь без чрезмерного всплеска деталей.Это часто помогает мне думать о тестировании и изменениях.Могу ли я выделить модель для тестирования?Могу ли я использовать совершенно другой вид, не меняя другие части?Могу ли я написать другой пользовательский интерфейс на основе той же модели?Как насчет другой «кожи»?Сколько бы мне пришлось переписать?

Answer 2

Модель данных.Контроллер это логика.Вид - это дисплей.

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

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

Таким образом, чтобы ответить на ваш вопрос.Вид должен просто сделать echo $this->view->myPentagon->someAttribute.Контроллер выбирает объект myPentagon из модели и назначает его объекту представления.Модель обрабатывает структуру данных и API базы данных.Вид обрабатывает дисплей.Контроллер сообщает представлению, когда отображать.

Answer 3

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

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