2010-09-14 4 views
1

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

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

Polygon - это информация содержит количество сторон и так далее. Это моя модель класса

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

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

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

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

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

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

Спасибо!

ответ

2

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

Какой вид не Остерегайтесь контекста, «истории жизни» отображаемого объекта. Это может произойти из сети, оно может скоро измениться, оно может стать вдвое большим, когда вы нажмете на него. Представление не волнует. Если вы нажмете на него, представление может сообщать о событии на контроллер и больше не заботится об этом. Если объект изменится, контроллер сообщит об обновлении.

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

0

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

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

0

Модель - данные. Контроллер является логическим. Просмотр - отображение.

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

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

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