Как правильно реализовать паттерн MVC?

Question

[Fedor]

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

Вопрос заключается в следующем:
/ru/category/city/subcategory/article

по поводу реализации патерна думаю как:
1. получение запроса пользователя контроллером (InController)
2. проверяем валидность адреса (оставляем только валидную часть) - подключаемая библиотека CheckURI
3. проверяем девайс пользователя (мобильный/планшет/десктоп) - подключаемая библиотека MobileDetect
4. проверяем авторизован ли пользователь
5. формирование массива входящих данных и выбор модели на которую поступят эти данные для обработки
6. определяем используемую модель (Mobile_Category) которая тянет данные из БД и определяет представление (Mobile_Subcategory)
7. передача данных на контроллер (OutController)
8. вывод пользователю

я просто хотел разделить контроллеры получающие данные и отдающие данные… пусть даже это будет 1 класс, но разные методы… но все же думаю о разных классах
а вот сам MVC реализовывать в порядке Model-View-Controller - сначала работает модель, потом подтягивается представление, и уже потом передача на контроллер
все что у меня выходит в первых 3 шагах - это что-то вроде подготовки данных

Поправьте, пожалуйста, и дайте щелбан если я где-то нарушил концепцию или накрутил лишнего.
Буду очень признателен сообществу :)

Answer 1

[Сергей Протько]

Ваша задача - не зацикливаться на аббривиатуре MVC и подумать над тем, как отделить HTTP от приложения. Для упрощения представьте что:

- view - это HTTP запрос и ответ. Это представление данных которое требует от сервера клиент.
- model - это ваше приложение которое ничего не знает о HTTP
- controller - это не один класс, а возможно целая цепочка классов, чья задача - абстрагирование модели от HTTP. Можно воспринимать ее как цепочку адаптеров. Запрос приходит в один адаптер - там разруливаем маршрутизацию, нашли контроллер - передаем дальше. Со временем адаптеры могут добавляться, например для добавления CORS или аутентификации могут быть дополнительные "адаптеры" (гуглить про middelwares, PSR-7 и т.д.)

Так же не забываем про принцип инверсии контроля (Inversion of control). Фреймворк должен вызывать ваш код а не ваш код дергать фреймворк. То есть именно контроллеры дергают модель а не наоборот. Модель ничего не должна знать ни о view ни о контроллерах.

Удачи.

p.s. я описал mediating controller MVC, оригинальный же паттерн MVC 79-ого года на бэкэнде не применим.

p.p.s. Перед имплементацией MVC рекомендую познакомиться с такими инструментами как composer. И например роутер сходу не писать свой. И ради бога не используйте PHP как шаблонизатор (гуглить про то что такое XSS), возьмите twig.

p.p.p.s https://github.com/pmjones/adr - рекомендую ознакомиться.

Comments

[copal]

MVC 79-ого года на бэкэнде не применим.

Каждый раз ваши ответы становятся все более пугающее, такое ощущение что Вы честно пытаетесь во всем разобраться, но от обильного потока данных запутались.
Игровой сервер, сервер какого-то ПО, например visual code или atom с могут и должны быть реализованы по mvc. И уже пора начать расставлять все точки и смело говорить что для обычных приложений на сервере используют не mvc, а mvp где баллом правит контроллер делая выборки из модели передает их в представление. Правда контроллер назван Презентер, но у меня сложилась привычка и я всегда называю его контроллером.

[Fedor]

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

PS: ни в коем случае не юзаю РНР как шаблонизатор :) те кто говорят "РНР и есть шаблонизатор" будут гореть в аду! :)

[Fedor]

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

[copal]

Fedor: Вы описали mvp.

[Сергей Протько]

copal: если что - я же написал что MVC 79 ого года в web не работает, а от того я описал MVA.

Проблема автора вопроса в том что он хочет реализовать MVC но не понимает зачем он ему нужен. Мы собственно с вами уже обсуждали эту проблему.

p.s. Давно не виделись)

Fedor: Да, вы описали MVP или же mediating controller MVC или же MVA. Разница только в том как происходит "работа с представлением". В Presenter у нас есть один презентер. В MVA у нас есть цепочка адаптеров (от одного до бесконечности).

[copal]

Сергей Протько: ну mvc 79 это -> m -> v -> c -> и вот как раз это mvc очень просто использовать и в вэбе. Ведь кто Вам запрещает серверную чать atom перенести на удаленный сервер и конектится к нему из обычного браузера. Или вот любые игры на php тоже дело распространенное и это тоже вэб и самое главное что желание написать правильно должно привести к mvc 79, а если кто-то скажет что он может по другому как-то сделать, то все что угодно можно сделать, только вот это не будет правильно.

Да ну 90% включаю опытных разработчиков и то наверное не понимают для чего им mvc и ему подобные архитектурные решения, это нормально. Главное понять ПРЕДНАЗНАЧЕНИЕ и тогда будет понятно что контроллер с точки зрения mvc и с точки зрения ооп должен быть только контроллером и знать только то что он контроллер.
Он должен иметь знания как работать с моделью и представлением и ничего не знать о каких-то валидаторах и прочей ерунде, которыми уже декорируют путь от контроллера к чему-то или от роутера к контроллеру.

[Сергей Протько]

copal:

ну mvc 79 это -> m -> v -> c -> и вот как раз это mvc очень просто использовать и в вэбе.

В WEB намного удобнее применять MVA:

Request -> Adapter1 -> Adapter2 -> Adapter3 -> Model -> Adapter 3 -> Adapter2 -> Adapter1 -> Response

Это удобнее с точки зрения HTTP во всяком случае. Этот протокол подразумевает возможность построения такой цепочки адаптеров или мидлвэров если хотите.

Ну и опять же, MVC подразумевает довольно длительный цикл существования View, к примеру "пока пользователь находится на этом скрине". С точки зрения сервера же, который выплевывает HTML, вью ограничено временем жизни формирования респонса (то есть даже меньше времени обработки запроса). Да и оно пассивно.

только вот это не будет правильно.

В случае с классическим MVC у нас View и Controller завязаны на Model. Не говоря уже что на сегодняшний день делать активные вьюшки - избыточно. Потому то почти все используют вариации MVP/MVVM/MVA. Просто потому что сегодня это удобнее. А правильно/неправильно - это дело такое.... если это работает и это удобно - то значит это правильно.

Главное понять ПРЕДНАЗНАЧЕНИЕ и тогда будет понятно что контроллер с точки зрения mvc и с точки зрения ооп должен быть только контроллером и знать только то что он контроллер.

Полностью согласен.

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

Мне потому очень нравится идея Model-View-Adapter. Оно не так жестко регламентирует что должно и чего не должно быть между View и Model. У меня например нет "классических" контроллеров. У меня запрос в одном из адаптеров мэпится на объект, происходит валидация данных и этот объект пропихивается в "хэндлер команды", или "экшен", или просто объект чья задача что-то сделать. Ответ формирует другой адаптер, используя закрепленный за этим маршрутом респондер. Причем есть четкое разделение ответственности, вроде бы выходит удобно (я не так давно начал так делать) и это приучает разработчиков делать много маленьких объектов а не дебильные классы менеджеры.

[copal]

Этот протокол подразумевает возможность построения такой цепочки адаптеров или мидлвэров если хотите.

Ну мне кажется не стоит упоминать о промежуточных архитектурных решениях в контексте mvc, это только запутывает. то есть посудите сами, когда говорят о mvc подразумеваю разделение логики от отображения. А начиная перечислять все подряд и размыливая до service или adapter или decorator, согласитесь, не айс вообще. То есть все кроме mvc, это промежуточные решения о которых не стоит говорить в контексте mvc. Это приводит к запутыванию, которое пугает людей.

Вот только сегодня рассуждал над проблемой непонимания ооп и мне кажется нашел причину и она та же что у mvc. Вот смотрите сами, я пишу приложение и использую самописное mvc что Выливается в несколько файлов даже на java. Все очень просто нет лишних медиаторов, проксей, декораторов и прочих паттернов, которые могут быть полезны при написании большого приложения. И вот я гордый что смог написать pure mvc, решил его закатать в фраймворк. И тут пришел кто-то и говорит что он столкнулся с ситуацией, когда нужны медиаторы. А другому понадобились прокси и декораторы, мосты, конечные автоматы, спецификация. А потом ещё и ещё стали приходить и просить добавить модели в виде коллекций и чтобы они json заправлялись.
И в итоге получился шатл. Теперь он долек от первоначальной затеи, но зато все угождает.
А что же я буду делать потом? Конечно писать мануалы и уроки, но не просто так, а заранее составлю пункты всех уроков и придумаю такое минимально приложение чтобы охватить все.
и в итоге получится хелловорлд с медиаторами и прочими сложностями которое я подам как спасение. Вот только я очень умный и забыл что когда-то был человеком, который после прочтения книги сел и пол дня не знал что тыкнуть чтобы что-то вывести на экран. и я забыл сказать что все это нужно применять только тогда, когда это действительно надо.
И вот значит пришли новички и решили что все эти тысячи медиаторов и прочего нужно писать всегда. Но естественно они усомнились, как и во всме по началу и пошли спрашивать у умных дедей, которые на вопрос - "а правильно ли использовать все это в контексте ооп" ответи "ДА", ведь оно так и есть, но только в нужные моменты. ооп это как витамины которые нужно принимать только в нужное время иначе пользы не будет. Но что Вы ответите если Вас спросят "нужно ли принимать витамины?", конечно "да!".
И вот как мне кажется, да оно так и есть, это понятно по тому что прежде всего ооп ругают за сложность и избыточность, в то время как все это вызвано банальной-глобальной человеческой ошибкой заключающийся в том, что все мы забываем что были когда-то глупыми не такими как сейчас. Да и занятость делает свое дело и вместо миллиона слов проще сказать что "да".

Вот так же и с mvc - гуру тостера сказал что на сервере не может быть правильного mvc из-за того что не делает те приложения, которые просто обязаны быть реализованными по правильному mvc иначе исполнители столкнуться со сложностями и будут потом говорить что mvc это фигня и они на собственном опыте изобрели что-то вроде mmvcmps. А на деле они из mvp сделали не до mvc.

Когда мы обсуждаем паттер конечные автоматы мы не будем обсуждать паттерн стратегия.
Почему когда мы обсуждаем mvc мы упоминаем адаптер?

Не говоря уже что на сегодняшний день делать активные вьюшки - избыточно. Потому то почти все используют вариации MVP/MVVM/MVA.

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

и это приучает разработчиков делать много маленьких объектов а не дебильные классы менеджеры.

Я некоторое время назад хихикал над Вами когда Вы все в сервисы закручивали, а сегодня АДАПТЕРЫ :) Так можно вообще создать просто А адаптеры и все в них нафигачивать и тоже получится.

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

Вам совет, сделайте игру с активной моделью и чтобы эту игру можно было с легкостью на разные фраймворки портировать. или подумайте хотя бы над этим. Как бы Вы сделали игру если бы в ТЗ входило что она-игра-(модель игры) легко реализовываться на любом из современных фраймворках. понимаете, модель приложения, это как двигатель в авто, который будет работать независимо от остальной части и не важно к чему его прикрутят. И все-таки лучше сделать чтобы на лицо увидеть что должно быть в модели, а что нет. Мне кажется Вы очень удивитесь. И если вас игры не привлекают, то поймите что точно так же будут писаться и другие сложные приложения не являющимися сайтами, а как например онлайн 3d редакторы, которыми я жутко увлёкся и вообще погрузился в 3d и делаю как раз первую 3d игру. И оказывается что даже моделировать у меня чуть-чуть получается. И как раз польза для будущего, так как делаю её на webgl.

[copal]

Сергей Протько: забыл Вас упомянуть, текст выше.

[copal]

Сергей Протько: сказал Вам чтобы попробовали, а для чего так и не договорил. Когда Вы сделаете правильное приложение с правильной моделью, такое что его можно будет легко портировать на все фраймворки, Вы поймете что такое модели и что к ней вообще не относится. И только тогда Вы поймете что то что сегодня Вы понимаете как не представление на самом деле является сложным состовным представлением. Вы должны понять что компонент TextArea не имеет модель со значением text, а объект который хранит строку является такой же частью представления. И что то же redux это всего-лишь библиотека для работы с представлением.

[Сергей Протько]

copal:

Когда Вы сделаете правильное приложение с правильной моделью, такое что его можно будет легко портировать на все фраймворки

Как правило у меня "модель" ничегошеньки не знает о фреймворке. А все инфраструктурные штуки сокрыты от модели при помощи инверсии зависимости (не путать с иньекцией).

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

Я не претендую на звание "гуру" и т.д. Я просто знаю зачем придумали MVC и какие проблемы оно должно было решать. И почему придумали потом MVP/MVVM/Flux/Viper и прочие штуки.

Вы должны понять что компонент TextArea не имеет модель со значением text, а объект который хранит строку является такой же частью представления.

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

Вы опять не правы. сегодня как никогда раньше используют активные вьюшки.

Где? Я серьезно, я может чего не понимаю, но где? Намекните хоть куда копать.

Я некоторое время назад хихикал над Вами когда Вы все в сервисы закручивали, а сегодня АДАПТЕРЫ :)

А как по вашему надо?) Да, у меня модель представлена совокупностью сущностей, объектов значений и сервисов. Вы знаете способ выражения модели лучше? Поделитесь.

[Сергей Протько]

copal: про игру - попробую. Я на днях обсуждал с одним знакомым эту проблему, и как бы... вроде бы небыло никаких проблем, но честно - я ни разу не писал игрушек. Максимум примитивный графический движек. Тут проблема как всегда - это надо придумать что делать. Если подскажите примерчик игрушки - буду благодарен.

[Fedor]

Сергей Протько: в принципе я понимаю зачем мне это нужно) проблема в том, что я не понимаю пока "как мне это нужно" реализовать...
если выразить графически MVC (https://habrastorage.org/storage2/96c/f77/c32/96cf... и MVP (https://habrastorage.org/storage2/899/1b8/95c/8991... - то наиболее логичным и простым мне кажется реализация MVP - она как-то проще выглядит...

[copal]

Сергей Протько: одно из самого простого это морской бой. Вся игра вся логика игры находится на сервере. Как все происходит... К серверу подключается (соккет серверу) игрок и дожидается второго игрока в очереди. Как только есть с кем играть создается комната с инстенсом игры и дальнейшие действия переходят под управление модели. Модель шлет клиентам событие и говорит что нужно расставлять корабли, на что у них есть минута по истечению которой модель сама расставляет корабли.
Дальше все просто - клиент пошел, сервер проверил допустимый ход или нет и если да, то делает ход и делает соответствующие действия.
Эта простая игра покажет Вам что на сервере может быть стандартная реализация mvc и так же докажет что весь клиент, все кнопки и игровое поле и анимации и прочее, это все представление. То есть в морском бое вообще на клиенте нет модели.Хотя если Вы захотите предварительно валидировать ходы на клиенте, то можно создать модель которая будет иметь один метод типа проверитьДопустимостьХода и будет связываться с моделью на сервере и проверять можно пойти или нет.

И вот тут у Вас должен наступить ступор, ведь игровое поле очень сложный компонент, но это всего-навсего представление и те МОДЕЛИ КОМПОНЕНТА о которых Вы говорили всего-лишь выдумка. Модель которая делает препроверку, модель на сервере и все! Если у компонентов и есть модель, то только модель-представления, которая так и называется но по факту сбивает с толку все подряд, так как все думают что говоря о модели представления говорят о модели из mvc о модели приложения. Модель представления это всего-лишь вынесенные данные в виде value object для того чтобы со сложным составным было легче работать, легче его подстраивать и изменять.

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

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

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

[Сергей Протько]

copal: вспомнил что лет 7 назад писал гоночку примитивную.

А вот проверка столкновений с препятствиями на пути это уже дело представления

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

p.s. ну короч я попробую, и потом напишу вам.

[copal]

Сергей Протько: моделирование солкновений может и называется, но только в заумных книжках. Я ни разу не слушал из уст геймдевов такие жуткие слова :) Физическая модель, это когда Вы физические движки используете, я же предлагаю делать очень простые игры чтобы разработка принесла радость, а не чтение заумных книг тонну.

Для меня представление === view, оно является всем что не бизнес модель === model, ну и естественно не контроллер. Когда я говорю представление, я подразумеваю все от картинок и текста, то твинов и физических движков, да хоть самого webgl, это все вью. И столкновения проверяет вью, вся физика, это тоже вью. Естественно реализация проверки столкновения будет вынесена в сервис... Но сервис это абстрактное понятие которое на жаргоне программистов означает код которые вынесен откуда-то и его легко заменить. Не более. И главное хочу напомнить, что проверки инициируются вью и происходят во вью. Не в контроллере. умная полноценная вью и активная полноценная модель. Контроллер нужен лишь для ... вью обнаружила столкновение, послало событие, которое поймал контроллер и сказал об этом модели.

И ещё раз - представление включает в себя и презентационную логику и все-все-все.
Вообще в вэб играх существуюет иерархия из MainModel которая получив команду от модели устанавливает LobbyView или GameView, которые в свою очередь собирают экран и являются связующим звеном своей части.

[Сергей Протько]

copal: Звучит логично, вроде бы... но меня категорически смущает отсутствие каких-либо ограничений и мутное разделение обязанностей. В частности меня крайне смущает формулировка "детектинг коллизий это часть view".

Для начала чисто абстрактный пример простенькой гоночки. И если можно, прочтите до конца, а то я старался.

Вот у нас есть 3d моделька машинки. Ее представление - совокупность треугольников, представленных набором координат xyz в относительных единицах (float-ты допустим). Это не пиксели и т.д. Это просто координаты точек векторной 3D модельки.

Теперь нам нужно отобразить эту модельку пользователю. Например при помощи WebGL. Для начала давайте определимся какое представление хочет получить пользователь. Он хочет получить 2D проэкцию этой картинки, с учетом глубины, с закрашенными треугольниками, со сглаживанием линий и т.д.

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

Теперь подумаем дальше. Коллизии. Как обычно они реализуются? Обычно это чуть более упрощенный вариант той же 3D модели (с много меньшим количеством треугольников для упрощения общета). Например в случае гоночек (если мы не хотим делать сложную модель повреждений и т.д.) машинка может быть очень детально прорисованной, а ее модель столкновения может состоять из пары десятков треугольников.

Далее... логично такие вещи как просчет пересечения объектов тоже на GPU считать, для этого мы можем так же написать парочку шейдеров и заюзать WebGL для этого добра. Но если в примере выше мы при помощи шейдеров конвертировали одно представление (3D вектор) в другое (2D растр), то в случае модели столкновения мы всего-лишь узнаем "пересекаются ли два 3D векторных объекта". Представление данных не меняется никак. И более того, именно эта модель влияет на положение объектов. Скажем если два объекта столкнулись, мы можем учесть упругость объектов, скорость и просчитать отскок. То есть координаты объектов будут расставлены в соответствии с смоделированным поведением оных.

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

Теперь давайте подумаем, откуда мы возьмем скорость и прочее? У пользователя есть устройства ввода. Работу с устройствами ввода на себя берут контроллеры. Они получают события о том что чувак "нажал и удерживает клавишу вперед", и просят модель отреагировать. То есть наша "модель" должна "смоделировать" действие "вперед". Например просчитать ускорение и новые координаты объектов. Опять же система координат используется без привязки к физическому экрану и т.д.

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

Теперь что до сервера. Представим что это многопользовательская игрушка. От реализации графического движка мы решили "отделиться", и в итоге модель ничего о нем не знает, о графическом движке знает только вьюшка. Однако нам нужно "синхронизировать" действия между клиентами, и потому мы прокидываем координаты объектов по сети. Клиенты уже будут учитывать эту информацию для обсчета столкновений и тд. и будут прокидывать информацию о оных друг дружке. Причем вот этот момент не зависит от "графического движка" или представления. Это очень важный аспект многопользовательской игрушки. Так что мы не можем отделить обработку коллизий от модели.

[copal]

Сергей Протько:

Работу с устройствами ввода на себя берут контроллеры.

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

Ну а дальше я согласен, что если гонки мультиплеер, то да, просчет столкновений обязательно на сервере и этот просчет будет являться частью модели. Действия тогда будут вот примерно какие - вью каждый кадр посылает события с координатами машинки и что-то ещё, то нужно. Контроллер ловит и отсылает эти данные на сервер. На сервере все ещё раз проверяет и если столкновение действительно было, то снимаются показатели скорости и положения и рассчитывается урон, который от-сы-ла-ет-ся... на клиент! Похоже и правда mvp опять получается... Ведь в случаи с мультиплеером в моделе на клиенте просто нет смысла, а это означает что серверная модель пошлет событие которое будет ловить контроллер и передавать в представление будет тоже контроллер.
Но вот если прикинуть что узнавать у сервера сколько максимально может развить скорость машинка чтобы не привысить предел на спидометре, это же согласитесь глупо. Ведь предел не изменится и значение по ходу заезда не меняется, а значит нужно эти значения просто захешировать на клиенте. А это данные ни разу не представления, а значит все же нужно завести модель. И это только начало, наверняка наберется маленькая тележка на полноценную модель, которая и установит связь с сервером и все встанет на свое русло.

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

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

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

[copal]

Сергей Протько: и вот mvvm я бы тоже не спешил применять так как это стопудово сотрет грань между "возможно отдаленно напоминает модель" и "вообще ни разу не модель".

[Сергей Протько]

copal:

Давайте вспомним что контроллеры созданы для связи представления и модели, это их первостепенная задача.

пруф в студию. Я вам уже как-то кидал ссылку на статью за авторством.... Trygve Reenskaug... на тему того что контроллера работали с редакторами и оригинальный датафлоу был:

Editors |-> Controller -> Model |-> View.

при помощи "|->" указаны связи через обзервабл отношения.

просчет столкновений обязательно на сервере и этот просчет будет являться частью модели.

Зачем на сервере? Зачем создавать себе головную боль? Все на клиенте. Связь между клиентами - UDP. Нет сервера, хоть p2p делай.

[copal]

Сергей Протько:

Зачем на сервере? Зачем создавать себе головную боль? Все на клиенте.

Если игра мультиплеерная, то обязательно на сервере так как игроки будут читерит и это единственный способ защитить, а значит не потерять честных игроков. Поэтому даже обсуждать не стоит - проверка на сервере и точка. То есть сервер должен знать о положении каждого авто, его скорости и повреждениях в каждом кадре. И мне кажется что для модели MP игры это максимум.

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

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

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

В общем пока бы я делал так как написал, но не совсем уверен что прав.

[Fedor]

copal: Сергей Протько: господа)) "нашла коса на камень")))
не забывайте 2 пословицы:
- из двух спорящих один дурак, а второй подлец
- правда всегда где-то посредине

:)

[copal]

Fedor: мне кажется мы с Сергей Протько: не спорим, помогаем друг-другу разобраться. По крайней мере я вступая в дебаты рассчитываю получить то что получил в этом разговоре - возможность подумать о чем-то что ещё не делал, чтобы избежать ошибок в реальных условиях.
Лично я вправду подзабыл что контроллер работает с пользователем и у меня этим часто занимается что-то другое и даже представление. По факту сама вью не слушает ничего, всегда есть объект который слушает представление и дергает представление и это единственно верный способ тестирования и замены пользователя, например ИИ.
Но я всегда считал что это тоже представление, теперь буду приписывать что это ControlController :)

[copal]

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

[Сергей Протько]

Fedor: аналогично. Товаристч copal: в своем упорстве заставляет меня придумывать более понятные примеры (я надеюсь что они стали понятнее с наших первых бесед) и в целом я нахожу наши дебаты полезными)

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

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

[copal]

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

Answer 2

[Mr Hobot]

Взять самый легкий фреймворк codeigniter и подсмотреть не вариант? За день два разберетесь, там и поймете что хотите. У вас все очень классно разписано, не спорю, но реализовать это с начальными знаниями(как вы говорите) и без знания каких либо других фреймворков будет тяжело если не возможно. В голове картину нарисовать легко, попробуйте её на холст перенести). Почти у всех кто пробывал сделать свой фреймворк была такая история:"Нарисовал идею в голове/бумаге, начал пробывать пилить, пилишь пилишь. -Тьфу дерьмо какое!!!... Снес все под чистую. Начал с нуля. Этот пункт повторяеться 3-5 раз в зависимости от настойчивости(овны и козероги привет). Потом береться фреймворк, смотриться что и как сделано. Пытаемся взять основную идею, но сделать по своему. Пилим пилим. Опять пункт про " -Тьфу дерьмо какое!!!.Сносим". В итоге повторяем почти все, но допиливаем что-то свое, что кажеться нам нужным и уместным. В итоге из таких вот франкинштейнов потом выходят свои cms , которые они знаю вдоль и поперек(сам же пилил, пыхтел) и возможно даже используються(некоторые так и пилят сайтики на своих cms, когда видят что дописывать функционал к "своему детищу" куда легче чем допиливать wordpress)". Такие вот дела. Пробуйте, пригодиться.

Comments

[Сергей Протько]

codeigniter плохо показывает суть MVC. Как и фреймворки вроде Yii и т.д - это скорее легкое извращение самой идеи.

[Mr Hobot]

Сергей Протько: его упомянул только ради простоты. Вряд-ли он потянет сразу symfony.

[Mr Hobot]

Сергей Протько: и раз уж вы тут, хотелось бы задать вам один вопрос. Есть ли смысл и перспектива в том что бы забить юх на php/python/ruby сейчас и углубиться в фронт(жесткий с фреймворками и перенесенной некоторой логикой из бэкэнда) + node.js. Душа тяготеет к фронту, но не хочеться что бы опыт бэкэнда зря пропал.

[Fedor]

Спасибо за Ваш ответ.
Вот с фреймворками какая история - мне видится так, что для перехода на фреймворк необходимо минимально освоить РНР как такого и шаблоны/методики написания...

Я отдаю себе отчет в том, что:
- это будет "Тьфу, говно какое" и постоянные сносы кода
- это будет долго
- и очень долго, хотя я и не овен/козерог))) но упрямства не меньше

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

Вы ведь тоже не сразу фреймворки пользовать начали?))

[Mr Hobot]

Fedor: нет конечно же. Я и не думал вас уводить с этого пути) Набить шишки должен каждый. Неотьемлимая часть жизни программиста.

[Mr Hobot]

Fedor: на счет "Тьфу, говно какое". Если вы будете смотреть на свой код полугодовой давности и не думать "Тьфу, говно какое", бейте в колокола вы остановились в развитии)

[Fedor]

Троцкий 2.0: естественно... я через каждые 3-4 дня стираю все что наговнокодил))) так что пока не переживаю

[Сергей Протько]

Троцкий 2.0: symfony не MVC фреймворк, это request/response фреймворк.