MVC на phppatterns.com

[Духовность™]

MVC на phppatterns.com

http://www.phppatterns.com/docs/design/mvc_pattern_version_2

    //! A constructor.
    /**
    * Constucts a new ProductView object
    * @param $model an instance of the ProductModel class
    */
    function ProductView (&$model) {
        $this->model=& $model;
    }

тут view содержит в себе объект модели. это идеологически верно или нет? я думал, что только контроллер может иметь в себе объекты view и model, а сами view и model ничего не должны знать друг о друге.

 

[флоппик]

это идеологически верно или нет?

это спорный вопрос

Но он не соделжит в себе модели, а только ссылку на нее.

 

[Духовность™]

флоппик
ну какая разница )

я имею в виду, можно ли из view тягать данные модели? ведь получается, что если изменится модель, например, метод или тип выдачи данных, то надо менять и код view.

:Р

 

[флоппик]

Я по этому поводу видел очень много холиваров.

Видишь, если изменится модель, представление скорее всего и так изменится, что бы отразить эти изменения

Я видел у одного умного человека интересную вещь, у него каждая модель имеет state, состояние. И контроллер например, воздействует не на саму модель, а на ее state — view, в свою очередь, умеет отображать текущий state модели. Когда он писал это на php4 это изобиловало всяческими воркэраундами, а вот счас прикидываю с точки зрения php5 - могло бы вкусно получится... Например, если state реализовывал ArrayIterator, и тому подобное.

 

[Духовность™]

понятно )
ну ладно, пасиб.

 

[whirlwind]

Я думаю, что это не очень удобный подход. Давайте с этой схемой попробуем представить композитный контроллер. Ну, например, не продукт, а юзера и его последние топики. Как это будет выглядеть в данном случае? Тут уже для вида придется менять прототип конструктора, для того что бы передать объекты двух моделей, а это - изменение интерфейса. Если они вынесли вид на уровень модели, то почему не вынесли туда же HttpRequest, ведь это абстракции одного уровня: I/O ?

 

[rotoZOOM]

Как это будет выглядеть в данном случае?

Фасад?

 

[флоппик]

Я думаю, что это не очень удобный подход.

Я по этому поводу видел очень много холиваров.

 

[whirlwind]

Я думаю это дурацкая аббревиатура виновата

MV <- C ?
C -> M -> V ?

WTFW ???

 

[Духовность™]

C -> M -> V ?

ТАК!!

 

[whirlwind]

Если так, то C вообще про V не должен знать. Так хорошо сработает в интерактивных приложениях, но не с HTTP. Я вообще делал так

     M
     ^
     |
I -> C -> O

 

[HraKK]

whirlwind
+1

 

[Ravanger]

ИМХО, как раз M->V->C, попробую обьяснить

Возьмем в пример абстрактную программу

сначала у нас идет сбор и обработка данных (М) затем мы эти данные показываем конечному юзеру (V), а потом мы ждем от юзера ввода каких либо данных, чтобы отправить их на валидацию в контроллер (С) который в свою очередь отдает(или нет) эти данные в модель

поправьте если я не прав

 

[whirlwind]

 

[флоппик]

 

[Ravanger]

ну с изьяснениями у меня всегда тяжко было )

 

[whirlwind]

Ravanger а если не рассматривать сферических коней?

 

[Crys]

сначала у нас идет сбор и обработка данных (М) затем мы эти данные показываем конечному юзеру (V), а потом мы ждем от юзера ввода каких либо данных, чтобы отправить их на валидацию в контроллер (С) который в свою очередь отдает(или нет) эти данные в модель

Конечный юзер не является "View".

 

[Духовность™]

млять, нихрена у меня не получается MVC. В том смысле, что код с MVC раздувается в 3 раза.

Вот смотрите, есть страница: http://mensland.ru/faq

без MVC там 66 строк кода. Вот что получается с этим решением: http://phpclub.ru/paste/index.php?show=2193

Посмотрите, что там не правильно.

 

[Santiago]

triumvirat
Ну как минимум:
1. Если уж ты хочешь во view иметь доступ к модели (хотя по мне так это совсем необязательно), то работать надо с одним объектом модели, а не с двумя разными в контроллере и view.

2. Отправка почты не имеет отношения к данным (модели).