Пара философских вопросов о MVC

[silin]

МВЦ это мировой заговор, не пытайтесь в него вникнуть, если вы не член ложи

[JackFromChaos]

По поводу серверных приложений, мне тоже кажется что все должно обстоять несколько иначе.
Что обычно есть сервер? Это прежде всего модель. Теоретически, ну или в идеале, она полностью заменяет собой клиентскую модель через RPC систему. Типа тонкий клиент. В жизни это не работает – очень накладно получится и по нагрузки на сервер и по трафику. Соотвественно, имхо, логично сделать клиентскую «тонкую модель», которая кэширует какие то данные, получает команды, но вместо того, что бы исполнять(моделировать) у себя, делает запросы на сервер, получает ответ, на основе него модифицирует какие то данные(своего локального кэша), диспачит соответствующие события о изменениях.
При этом, кто бы не работал с моделью, ничего не заметит. Не важно, как работает модель, локально или через сеть, для клиета модели все работает так же.


2Хомяк: Я потому и задал вопрос, что пока не нашел никаких приемуществ MVC перед Docuemnt View like модели. Вот и решил разобраться. Или я чего то не понял, или MVC действительно просто модное слово (тока не бейте)

[Psycho Tiger]

Всё очень просто.
Есть у Вас модель "игрок". У игрока есть координаты x,y, размер, количество здоровья. И скажем это главный игрок и его здоровье выводится под самим игроком, в левом верхнем углу экрана, да ещё где-нибудь по другому, например в процентах. При изменении здоровья надо обновить его во всех трёх местах, поэтому важно разделять данные модель-представление.
Управление же данными должен делать контроллер. Например, в случае прихода сообщения от сервера - кто должен это сообщение разбирать? Там сказано - "игрок а переместился в точку б". Это сообщение должно пройти через все модели чтобы найти игрока "а" и переместить его в "б"? Совсем некрасиво. Кто-то должен получить это самое сообщение. Кто-то один. А потом уже дёрнуть нужную модель. Конечно, можно сказать что этим должна заниматься "самая-главная-модель". Только в итоге и получается, что эта самая-главная-модель, управляя данными сама в конечном счете уже превращается по описанию в контроллер.
Или, например, нужно полностью изменить поведение для уже имеющегося объекта. У объекта есть вью и модель, а вот нужно создать дубликат, но совершенно с другим поведением. В случае с контроллером - берём чистый контроллер и пишем код там, с 0. С ясной головой, спокойно. Без контроллера - придётся наследоваться и придерживаться "старых" правил, которые были в базовом классе.

[TanaTiX]

это сейчас не модно...

Не понимаю я таких высказываний в программировании.

[Хомяк]

Сообщение от Psycho Tiger

Всё очень просто...

Могу быть не прав, потому, что речь идет об абстрактных предметах и мы можем понимать их по разному. Но.

Сообщение от сервера должен получать запрашивающий.

Изменить поведение модели можно переопределив её "поведенческие" методы. Что мешает?

[JackFromChaos]

Сообщение от Psycho Tiger

Всё очень просто.
Есть у Вас модель "игрок". У игрока есть координаты x,y, размер, количество здоровья. И скажем это главный игрок и его здоровье выводится под самим игроком, в левом верхнем углу экрана, да ещё где-нибудь по другому, например в процентах. При изменении здоровья надо обновить его во всех трёх местах, поэтому важно разделять данные модель-представление.

Это понятно. Вопрос не в то, надо резделять данные и представление, или нет...

Сообщение от Psycho Tiger

Управление же данными должен делать контроллер. Например, в случае прихода сообщения от сервера - кто должен это сообщение разбирать? Там сказано - "игрок а переместился в точку б". Это сообщение должно пройти через все модели чтобы найти игрока "а" и переместить его в "б"? Совсем некрасиво. Кто-то должен получить это самое сообщение. Кто-то один. А потом уже дёрнуть нужную модель. Конечно, можно сказать что этим должна заниматься "самая-главная-модель". Только в итоге и получается, что эта самая-главная-модель, управляя данными сама в конечном счете уже превращается по описанию в контроллер.

Ну тут допустим пусть так. Хотя не так важно, как это назвать, контроллер или модель. Тем более, что в класической схеме контролер все таки прослойка между пользователем и моделью, а не между моделью и моделью(сервер/клиент).

Сообщение от Psycho Tiger

Или, например, нужно полностью изменить поведение для уже имеющегося объекта. У объекта есть вью и модель, а вот нужно создать дубликат, но совершенно с другим поведением. В случае с контроллером - берём чистый контроллер и пишем код там, с 0. С ясной головой, спокойно. Без контроллера - придётся наследоваться и придерживаться "старых" правил, которые были в базовом классе.

А это уже очень спорно.
Опять же, "бизнес-логика" внутри контролера, а не в самой модели - опять же уход от классической MVC.
И я прибываю в полной уверенности, что модель поведения модели, это исключительно прерогатива модели. Иначе мы получаем нет MVC, а MC/V/DB- при этом называя DB- моделью...

Добавлено через 7 минут
Логика, которая допустима на стороне контролера - это способы интерпретации действий пользователя в термины модели. Например, вплоть до размытия понятий игрока до понятия "абстрактного субъекта игровой модели".

Добавлено через 14 минут
Цитата из вики:
"Наиболее частые ошибки

Начинающие программисты (особенно в веб-программировании) очень часто трактуют архитектурную модель MVC совершенно неправильно. Они рассматривают Модель (Model) исключительно как совокупность функций и/или методов для доступа к данным, а Контроллер (Controller) как элемент системы, содержащий бизнес-логику. В результате код Моделей по факту является средством получения данных из СУБД, а Контроллер представляет собой типичный модуль, наполненный бизнес-логикой или скрипт в терминологии веб-программирования. В результате такого понимания MVC разработчики стали писать код, который известный в кругах Zend Framework сообщества разработчик Pádraic Brady охарактеризовал как ТТУК — «Толстые тупые уродливые контроллеры» (Fat Stupid Ugly Controllers)"

[Хомяк]

Суть дела не в том, чтобы во что бы то не стало придерживаться MVC. МVC- это попытка разделить процессы программы: отображение, прерывание, данные. При этом организовав их взаимодействие как отдельных, самостоятельных сущностей.

[Psycho Tiger]

Сообщение от сервера должен получать запрашивающий.

Окошко для покупки вещи. Окошко должно получить информацию о том, что вещь куплена?
А если окошко говорит контроллеру, то все сообщения получает контроллер.

Тем более, что в класической схеме контролер все таки прослойка между пользователем и моделью, а не между моделью и моделью(сервер/клиент).

Модели сервера, базы данных и всё остальное клиента как-то совершенно не волнуют. Он отправляет запрос и получает ответ. Из базы данных, из мемкеша или вообще сгенерированный в рантайме - ему побоку.

"Поведение модели - пререгатива модели" вообще легко опровергается. На том же примере - объектов с координатами много, а как менять координаты модель не касается. Модель может изменять себя только на основании внешних команд. Это как "переместится из а в б за 2 секунды" - модель вполне может менять свои поля x,y эти 2 секунды.

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

Правильно. А какая ещё логика бывает? Пользователь ввёл текст - отправили в фильтр модели, обновили представление вместе с фильтром.
Только ещё сюда стоит добавить сервер.

[silin]

Сообщение от Psycho Tiger

Всё очень просто.

каждый зверь смотрит на этот мир сквозь призму своего вида ( не MVC)
ну и на хрен мне это мне мвц, подумал этот подвид этого подвида : я что встречусь когда-то с цивилизацией, которая, которых.., т.е. там все это внимательно?

Добавлено через 53 секунды
сори, ухожу..

[mikhailk]

Опять же, "бизнес-логика" внутри контролера, а не в самой модели - опять же уход от классической MVC

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