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

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

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

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

Хорошая архитектура symfony app?

Михаил: https://gist.github.com/fesor/410adfc772daa7df2c5b...

Владимир Балин: повторюсь. "Архитектура" = "общее понимание". То есть все сугубо в контексте нужно рассматривать. Но если говорить о сферическом в вакууме.... то интерфейс нашего объекта файдера будет представлять собой "границу" или "порт" для слоя предметной области, или проще говоря того слоя, в котором реализована логика приложения. А реализация этого интерфейса - это часть инфраструктуры.

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

copal:

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

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

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

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

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

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

Хорошая архитектура symfony app?

Михаил: в Yii2 используется ActiveRecord. там нет таких вещей как "репозиторий". Там вместо этого - статические методы фабрики, которые могут "воссаздовать объект" из записи в базе данных. Если у вас выборки сложные - вы можете вынести из "статического метода" в "просто фабрику". Мне нравится называть такие фабрики Finder поскольку это именно то, что они делают. Они ищут информацию в базе и восстоздаю из нее объект. И вот для этих "файнедров" при наличи у них интерфейса мы можем написать "декоратор" который будет заниматься кешированием.

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошая архитектура symfony app?

Михаил: эм.... а с чего бы контроллеру об этом знать? Он все так же ожидает инстанс FooRepository. То что он получает инстанс FooRepositoryCache имплементящий интерфейс FooRepository - это не значит что он знает что получил.

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

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

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

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

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

Как правильно составить условие?

Secret73: опять же если не собираетесь переходить - посмотрите эквивалентную запись для php5

Как правильно составить условие?

Secret73: потому что php7, переходите на него.

Как прервать выполнение метода контроллера в Symfony?

Кирилл Несмеянов: ээх... ты сначала мэпишь аргументы по типам, а симфони уже по именам их расставляет. Вроде ж все понятно.

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

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

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

copal:

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

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

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

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

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

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

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

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

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

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

Как отследить нужную комбинацию в массиве?

Muhammad: тоже верно

Как настроить сеть в Docker?

я не очень понял что вы хотели сделать через курл.... ну мол.... вы хотели IP адрес хост машины взять?

Как отследить нужную комбинацию в массиве?

5 === count(array_unique(array_intersect(range(1, 5), $arr)));

одна строчка.

Как правильно реализовать паттерн 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. У меня например нет "классических" контроллеров. У меня запрос в одном из адаптеров мэпится на объект, происходит валидация данных и этот объект пропихивается в "хэндлер команды", или "экшен", или просто объект чья задача что-то сделать. Ответ формирует другой адаптер, используя закрепленный за этим маршрутом респондер. Причем есть четкое разделение ответственности, вроде бы выходит удобно (я не так давно начал так делать) и это приучает разработчиков делать много маленьких объектов а не дебильные классы менеджеры.

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

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

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

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

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

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

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

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

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

Как прервать выполнение метода контроллера в Symfony?

Кирилл Несмеянов: вообще-то все твои "аргументы" которые ты хочешь пропихивать через дабл диспат должны быть привязаны к конкретному реквесту. И их толга вполне логично добавлять как атрибуты запроса. А там уже симфони сама все по аргументам распихает.