как правило, получение данных ввода пользователя должны быть на вью, причём и в Mvp и в Mvc, а вот их интерпретация (валидации, обработка) - уже ответственность контроллера (ну или презентера). Хотя как я говорил, интерпретация может разниться. Но отличия в Mvc и Mvp больше в зависимостях между компонентами, в частности в более пассивной вью.
@@RuslanSmirnovGameDev MVC классический был создан на основе философии компьютера, где controller это устройство ввода, view это устройство вывода, а model это бизнес модель. Но я согласен, что интерпретируют это все несколько по-разному сейчас.
@@sergeypogorelov7059 Разная интерпритация конректного паттерна от незнания кем и для чего "создавался" данный паттерн. Обычно такие люди не могут отличить MVC, MVP, MVVM, MVA. В особенности MVVM и MVA, так как у них "стрелочки почти одинаковые". Сейчас бы оригинальный MVC назвали сильно связанным, и любой di контаинер типо Zenject при попытке резолва такой зависимости выдал бы ошибку о "говнокоде" ) Да, перейти на события здравая идея (Как на схеме в начале видоса), но это уже и не MVC, тогда уж лучше пользоваться MVVM.
@@PragmaGames это да, в MVC действительно слишком много зависимостей, это очень непрактично, ну и как результат - почти нигде не используется (если говорить сугубо про геймдев).
А это разве не MVP? В MVC обработка ввода в controller должна быть, а у вас на картинке на View
как правило, получение данных ввода пользователя должны быть на вью, причём и в Mvp и в Mvc, а вот их интерпретация (валидации, обработка) - уже ответственность контроллера (ну или презентера). Хотя как я говорил, интерпретация может разниться. Но отличия в Mvc и Mvp больше в зависимостях между компонентами, в частности в более пассивной вью.
@@RuslanSmirnovGameDev MVC классический был создан на основе философии компьютера, где controller это устройство ввода, view это устройство вывода, а model это бизнес модель. Но я согласен, что интерпретируют это все несколько по-разному сейчас.
@@sergeypogorelov7059 Разная интерпритация конректного паттерна от незнания кем и для чего "создавался" данный паттерн. Обычно такие люди не могут отличить MVC, MVP, MVVM, MVA. В особенности MVVM и MVA, так как у них "стрелочки почти одинаковые". Сейчас бы оригинальный MVC назвали сильно связанным, и любой di контаинер типо Zenject при попытке резолва такой зависимости выдал бы ошибку о "говнокоде" ) Да, перейти на события здравая идея (Как на схеме в начале видоса), но это уже и не MVC, тогда уж лучше пользоваться MVVM.
@@PragmaGames это да, в MVC действительно слишком много зависимостей, это очень непрактично, ну и как результат - почти нигде не используется (если говорить сугубо про геймдев).
Это ж UI игра по сути, тут на MVVM написать кайфово было бы
можно было, но я так понял у автора было требование использовать MVC