mvc на более жизненном примере
 

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

Прочитал, начил накидовать минимальный пример и оказалось, что по инструкции кормления котенка, накормить льва не получается. Не складывается у меня картинка, а если и складывается, то получается вовсе не mvc.

Часть первая - человечек подошел к определенному месту на карте и модель ( на клиенте ) узнает об этом, после чего ей нужно создать, рандомно, врага. Чтобы создать врага, она должна послать запрос на сервер, чтобы серверная модель выбрала, создала и отправила этого врага.
Вопрос -
1) каким образом модель на клиенте свяжется с серверной моделью или образно говоря сервером?
2) Как сервер поймет, кому нужно отослать созданного врага?
3) Кто из членов должен получить этого врага?
4) После того, как кто-то получит этого врага, как он узнает кому передать его после получения?
5) Должна ли модель просить только модель, а после её получения она сообщит представлению, которое в свою очередь запросит с сервера картинку?
6) Как представление скажет серверу, что ей нужно?
7) Кто из членов группировки получит прешедшие с сервера наряды?
8) Как кто-то определит, какому представлению нужно отдать контент?

Да прибудет с Вами Сила.

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

Может, для упрощения восприятия mvc стоит упростить задачу? Лучше взять пример попроще: пятнашки, тетрис, гоночки. Понимаю, что хочется сразу с разбега создать онлайн мморпг в реальном времени, но для этого придётся учиться всему поэтапно, долго и упорно.

Дело в том, что пятнашки и калькуляторы я могу создавать, а сервер привел в пример, дабы картина была ясней.
Я могу представить сервер, где прешежшие запросы строятся в асинхронную очередь и модель создав врага диспатчнит событие и "что-то" асинхронное отошлет по записаному в поле обратнуму адресу... Могу представить нечто подобное и на клиенте, но ведь это уже не mvc. Могу представить на клиенте некий "комбаин", который молотит все попало и выдает то, что у него попросят.
И сложно это когда не знаешь, но ведь здесь наверняка есть люди и не мало, которые могут просто, без кода, расказать, а я не слабоумный смогу понять.

Обидеть вас у меня в мыслях не было. Просто хочу сказать, что учиться mvc можно и нужно на простых примерах.
MVC:

• https://ru.wikipedia.org/wiki/Model-View-Controller (Начать стоит с wiki)
• http://www.flasher.ru/forum/blog.php?b=256 (Весёлый блог про сиськи и mvc)
• http://www.ozon.ru/context/detail/id/5960370/ (Тут mvc разъясняется на хороших примерах)

Можно ещё пошарить поиском, тем про него десятки, если не сотни! Не все из них полезны.
Создавать и размусоливать очередную тему не хочется, воспользуйтесь ссылками.

Спасибо Вам за ссыли, но всё это я уже прочел. В вики, так же как и у Psycho Tiger пример кормления котят, как я уже и сказал в первом сообщении.
В жизни эта парадигма разбивается об "утес интерпритаторов головного мозга" до такой степени, что из представления модель меняют ( не хочу тоже никого задеть, но это в корне не правильно ). И чтобы не сотворить себе кумира я пришел к Вам, за истенным просветлением.
И единственное, за что стоит сжечь книгу по Вашей ссылке, это , как бы иронично не звачало, mvc. Читая книгу, получаешь истенное удавольствие и представляешь, как на главе о mvc он пошел за печенюгами и вместо него села сабака писать :) Там ведь ссылку на контроллер представление хранит.

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

И я не увидел в Ваших словах ничего, что меня бы задело. Про слабоумие я упомянул чтобы подчеркнуть, что смогу понять быстро и не садится на шею тому, кто решится помочь.

И простите меня, если для этого форума моя тема уже не первая, но я чесно искал все и читал все, что значится в поиске с mvc.

OlmerDale - какие то странные непонятные пункты вопросов.
Сначала нужно знать какой сервер, сокет, медиа или вообще по УРЛ тягающий. А дальше уже и идет разбор как с ним работать. Контроллер делает запрос на сервер, сервер дает ответ - пишем в модель, обновляем свой вид - все просто. Нужно дернуть сервер? еще проще - вид позвал контроллер, контроллер дернул сервер...

Добавлено через 1 минуту
никто так не делает

Добавлено через 4 минуты
Одна из возможных реализаций.
P.s. когда напишите хоть одну тяжелую программу на мвс - оно само собой придет к вам, и будет понятно - какой же способ реализации прилоежний вам нужен. Я остановился на MVC+MVP - и меня это устраивает полностью, я не вижу ни проблем в дальнейших реализациях, ни проблем дополнениях и т.п. короче я для себя нашел - что мне нужно, и так же каждый находит для себя, на чистом МВС - писать не получится все равно, как ни крути будут помеси

in4core - ну Вы извините меня за "непонятность" с серверами до сего дня не работал. И с сервером ещё до конца не определился, думаю что для начала легкий на nodejs + socket, но его можно опустить.
Вот Вы говорите -
Это у Вас представление контроллер просит и это естественно, но как быть если модели нужно что-то?
Она же не должна контроллеру говорит?
обновляем представление как? Ответ-то для модели пришел, да и то мы еще не поняли, как она его туда отправила?

Поверьте мне, есть такие.

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

С моедлью работает контроллер. Вот нажал ты на кнопку в представлении ( проще говорить в ВИДЕ ), отправил событие в контроллер BTN_PUSH контроллер поймал его и записал все что нужно в модель. Но это крайний случай, чаще всего все происходит на уровне сервера-контроллер-модели, а вид изредка подкидывает запросы контроллеру на дергание сервера - вот и все.

Шо значит КАК! У нас для этого сразу 2 схемы, как я выше сказал МВС-и МВП. По первой - вид подписался на модель и ждет изменния данных, то есть пришли данные с сервера, контроллер пихнул их в модель, можель отправило событие, вид его поймал и отобразил как надо. ВИД имеет ссылку на модель, НО дергать ее сам не должен :)
МВП - это когда напрямую, минуя модель - сервер дал, контроллер вызвал метод вида или записал ему какую то переменную.

Добавлено через 2 минуты
Да и честно говоря по большей части достаточно МВП, то есть безмодельные структуры. Модель можно бывает заменить неким Конфигом, или еще чем с этим связанным. Хотя я и пользую смешанную структуру, но 80% работы все таки идет по МВП, в средне нагруженных приложениях, как по мне

Добавлено через 6 минут
Раз уж распиался приведу более наглядный пример смешанной стурктуры. Допустим у тебя есть игра, в которой нет транзакционной модели ( не работаешь с деньгами ) , но баланс показать на экране надо. Ты его запросил с сервера - и сразу кинул в вид, минуя модель. Ну не нужно тебе его хранить, так как работать ты с ним не будешь никогда. В то же время в самой игре, ты изредка меняешь какие то параметры, например скорость движения машинки или еще чего, вот тут надо писать в модель, так как из за одного изменения, может поменяться несколько видов, напримр.
Так же это поможет от лишних запросов. Имея данные - ты можешь произвести проверку if(model.speed == 1) return, else sendNewSpeed, то есть не будешь лишний раз грузить проц ненужными телодвижениями.
Короче - все придет с опытом. Пробуй писать и все наладится)))

Вот я тоже так подумал, когда в первый раз прочитал её! :) Сейчас, когда я уже написал не одно большое приложение на таком ТТУК MVC, задумался.. Не то что-бы такие контроллеры были "толстыми" или "тупыми", просто вся логика работы находится в них. Модель напоминает субд а виверы - формы с гуи. На самом деле, это по своему довольно удобно. Средний контроллер имеет не более 250-300 строк кода и содержит только логику. Всё вполне расширяемо и казалось бы, нет никаких проблем. Но, это стремление к совершенству...

Не так давно, в целях саморазвития, начал применять практику "правильного" MVC, та что описана в той книжке. Опыта пока мало, но могу сказать, что тут есть свои плюсы. Например, модель становиться полноценной моделью, содержа в себе не только данные, но и логику их взаимодействия друг с другом. Вью стали чуть жирнее, так-как теперь инициация действий (слушатели ввода) находятся в них. Контроллеры напротив, очень сильно сжались и зачастую содержат в себе просто дублированную команду модели. Полностью аналогичный метод, который тупо дёргает такой-же метод модели. (Так и хочется дёрнуть его напрямую из вью, но - нельзя, парадигма)

Как тут говорят, у каждого своё MVC, но ведь есть же общие правила.
Мне и самому было-бы интересно услышать компетентное мнение по поводу сравнения ттук и "классического" mvc, но скорее всего, придётся познавать на практике.

Не люблю толстые контроллеры. Контролллер это работа с сервером и только, модель - данные и логика, ВНИМАНИЕ которая реально нужна модели. Все соатльное, подписки на ЕФ, клавиатуры, лоадеры, и прочяя ересь - все в вид.
Ну это имхо

Добавлено через 2 минуты
Опять же, неизвестно, что ты подразумеваешь под логикой контроллера. Если, что то типа
то это не совсем уж логика в моем понимании. Логика для меня это скорее определнный парсинг данных, обработка этих данных и т.п.

А я люблю толстые контроллеры.
Кстати, а почему не упомянули сервис?
Контроллеры общается с сервером(ами), страницей на которой флэшка, Http запросы итд, средствами сервисов.
Например, SocketServerService, JavaScriptService итд.
Удобно же.
Задачи на общение с внешним миром перекладываются на сервисы. Меньше кода в контроллере - проще его поддерживать, расширять итд.

Каждый это по своему зовет просто. Для меня SocketServerService - это тоже контролер, но только для сервера чисто и все. КОнечно ДА - они общаются напрямую , а как же еще? Это и упоминать не надо и так ясно.
Вид дал задачу, контроллер ее поймал, сообщил *сервису* - сервис вызвал команду сервера, сервер ответил, сервис отдиспатчил, контроллер поймал и т.д.