Pull to refresh
3

User

5
Subscribers
Send message
у меня есть обращение к Модели Контроллером:
$product = Product::Load($id)

> то контроллер иногда вызывает представление, то всегда
у меня (да, можете считать, что только у меня) Контроллер всегда вызывает Представление, просто не всегда обращаясь предварительно к Модели, и это самое важное

> шаблон Observe
это другой шаблон… Вы вольны его использовать, только не говорите, что этот шаблон — часть шаблона MVC, это сильно неправда
видимо, это вопрос религии, но моя религия в том, что Контроллер совсем всегда вызывает Представление (или его суррогат, когда сам Контроллер отдаёт HTTP-заголовок 404), и наоборот — Представление вызывает только Контроллер, а никак не Модель…
На практике для сокращения кода часто пытаются в метод Модели типа Product->Show(product_id) запихнуть вызов Представления Моделью, но это неправильное кун-фу (ИМХО)
Не надо путать…
«напрямую вызывает Представление» — имеется в виду, без обращения к Модели (ф-цмя Error)…
Это частный случай, а общий — Представление всегда вызывается Контроллером, как правило, что отобрадения результатов взаимодействия Контроллера с Моделью…
Но да, кому-то может захотеться вызывать Представление из Модели… Это плохой MVC, неправильный
Именно так… Её нет в этом определении, и это пичалька, потому что в результате этого неопределения возникают Тупые Жирные Контроллеры…
Издержки свободы восприятия простых определений…
Sun — голова…
Только я про то же:
3.2. В случае успеха – Представление для отображения запрашиваемых данных либо сообщения об их успешном сохранении (если Запрос 1 был на изменение данных).
Да, смишно…
На схеме частный случай MVC…
Давайте теперь изобретём новую религию на основе того, что контроллер может иногда напрямую вызывать Представление (в статье это ф-ция Error)?
Нет, из не моего определения следует, что Модель управляет данными, а Моделью управляет Контроллер.
Это очень просто.
Команду «Фас» даёт человек, а зубами по этой команде управляет собака.
Тут человек — Контроллер, а собака — Модель.
Философствования на тему того, что человек управляет зубами собаки, считаю признаком ;)
В правильном MVC есть события, их обрабатывает Контроллер, точнее, он в ответ на событие вызывает соответствующий метод Модели.
Он, возможно, и управляет данными, но не манипулирует ими, манипулирует Модель.
Может, расскажите уже, что за мифическая модель2? Судя по Вашим комментариям — какая-то майкрософтовская ересь
давайте рассуждать логически?
Контроллер — это управляющая Моделью и Представлением логика…
Представление — это представление (да-с)…
Модель — это манипулирование данными…
Вы реально думаете, что при таком определении нечто, именуемое бизнес-логикой, может быть в Контроллере или Представлении?
понятно, спасибо
это не моё определение

> управляющая логика есть, а где предметная?
В Модели, из определения этого разве не ясно? Пруф был дан (ещё раз спасибо rsvasilyev/) выше

> представление не зависит от модели, хотя в классическом MVC это не так
> Представление… вполне может получать данные от неё напрямую
Правильный MVC — это когда три компонента максимально независимы, а Модель и Представление взаимодействую только через Котроллер, а точнее, Контроллер «ими взаимодействует».
Подскажите, откуда Вы черпаете «классику»?
> Цитаты в студию
Видите ли, эта статья предназначена тем, кто только начинает изучать MVC, дабы они не погрязли в том обилии материала, где от MVC одно название. Поэтому я привёл то определение (заметьте, не моё), которое даёт максимально ясное понимание MVC. Цитат, которые запутают новичков, Вы от меня не дождётесь, ладно?

>> MVC — это образ мышления при проектировании веб-приложения.
>> MVC — это архитектурный шаблон, не более
э?..

> Вариант, что вы ошибаетесь, вы вовсе не рассматриваете?
в данном случае (что приведённое мной определение абсолютно верное) — полностью исключено

> ваше определение рекурсивно
чем писать столько букав, приведите определение, которое Вы считаете верным, будет проще обсуждать
Спасибо, роскошная статья, обязательно её попользую при следующих своих творчествах, если они состоятся
Определил я правильность, изучив 100500 определений и пояснений авторов разной степени авторитетности.
Приведённое мой определение является непротиворечивым как внутренне, так и внешне (по крайней мере по отношению к тем системам, которые придерживаются именно MVC, пусть и с теми или иными сопутствующими механизмами).

> в части .net полностью неверна
Эту статью я написал с одной целью — показать, что есть MVC, а что есть её интерпретации, развития или вариации с комбинациями. Примитивный код на PHP приведён для того, чтобы показать, что MVC — это совсем не «богатая» система классов типа Controller, View, Layout и прочих, коих легион, и многие из которых действительно полезны, а что MVC — это образ мышления при проектировании веб-приложения.
И если в .NET какая-то другая MVC (в чём я, кстати, сомневаюсь) — значит, там вовсе не MVC

Комментарии в стиле «а вот там не так, а вот у этого по-другому» говорят о том, что статья как раз актуальна, ибо там, где действительно «не так» — либо там не MVC, либо комментатор так и не уловил, где там MVC, а где другие, смежные паттерны
может, Вы приведёте примеры статей кого-то с лучшим пониманием MVC? можно даже не обязательно Ваших
я как раз имею в виду продолжение об этом написать, можете рассказать или направить, что же такое лейауты и какое они имеют место в MVC?
ну, или, выражаясь другими словами — по своей практике возникло ощущение, что за 10 лет MVC оброс таким количеством «вспомогательных» элементов и «вариантов», что самое время ещё раз напомнить, где MVC, а где «дальнейшее развитие»…
:)
эта статья есть попытка показать, где MVC, а где «варианты»…
ибо некоторые «варианты» на самом деле искажают, а местами сильно искажают то, что декларируется в MVC

Information

Rating
Does not participate
Registered
Activity