MVx паттерны в Unity. Кто лучше всех? ⚡️ MVC MVP MVA MVVM MVI MVE

• Приветствие зрителей и проверка связи.  

• Представление темы стрима: паттерны проектирования.  

• Настройка микрофона и обсуждение интерактивного конкурса.  

• Сравнение архитектурных и дизайн-паттернов.  

• Обсуждение канонических и неканонических реализаций паттернов.  

• Введение в паттерн MVC.  

• Описание паттерна MVC: модель, вид, контроллер.  

• История и происхождение паттерна.  

• Различие между классическим и современным представлениями MVC.  

• Применение MVC в десктопных и серверных приложениях.  

• Различие в реализации MVC в разных фреймворках.  

• Вопросы и комментарии по паттерну MVC.  

• Обсуждение основ работы паттернов.  

• Планы по сравнению паттернов и их реализации в Unity.  

• Вопрос о выборе между MVP и MVVM для Unity.  

• Обсуждение жизненного цикла компонентов и моделей.  

• Вопросы о связях между вью и контроллерами.  

• Нюансы обработки событий в MVC.  

• Обсуждение реализации MVC в Unity.  

• Роль контроллеров и моделей в MVC.  

• Примеры использования MVC в Unity.  

• Бизнес-логика и её распределение в зависимости от паттернов.  

• Варианты размещения бизнес-логики в контроллерах и моделях.  

• Пример с собеседованием и вопросом о паттерне MVC.  

• Двухслойная архитектура: модель, вью и контроллер на одном слое.  

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

• Модель и вью знают друг о друге, но общаются только в разные стороны.  

• Паттерн взаимодействия с юзер-интерфейсом: вью и контроллер на одном слое.  

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

• Модель и вью знают друг о друге, но общаются только в разные стороны.  

• Сравнение двухслойной и трехслойной архитектуры.  

• Вью и контроллер могут быть на одном слое, что делает архитектуру двухслойной.  

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

• Вопросы по архитектуре проекта: что где лежит, порядок инициализации, депенденси инжекшен.  

• Курс по архитектуре проекта рассматривает базовые вопросы, на которые юнити не дает ответа.  

• Курс включает подходы к управлению командой и процессам.  

• Тестирование в играх: мифы и реальность.  

• Курс по тестированию помогает избежать проблем, связанных с тестированием.  

• Тестирование должно быть интегрировано в процесс разработки, чтобы не мешать рефакторингу.  

• Паттерн MVC: модель, вью, контроллер.  

• Адаптер находится между вью и моделью, что делает архитектуру трехслойной.  

• Адаптер разделяет модель и вью, что улучшает тестируемость.  

• Бизнес-логика лежит в адаптере.  

• Модель может быть анемичной или объектной.  

• Адаптер абстрагирует модель от вью, что улучшает тестируемость и разделение задач.  

• Адаптеры могут привязываться к разным вьюхам, обеспечивая совместимость интерфейсов.  

• Вьюхи могут реализовывать один и тот же интерфейс, но с разными реализациями.  

• Адаптеры могут быть разными, реализуя разную бизнес-логику и отображение.  

• Адаптеры могут меняться в зависимости от ролей пользователя.  

• Методы адаптеров могут быть защищены от прямого вызова для пользователей без прав.  

• Адаптеры могут изменяться в зависимости от месяца и других бизнес-правил.  

• Вью слой обязателен в реализации Unity, так как он отвечает за отображение.  

• В Unity нет готового паттерна для вью, что требует создания фреймворка.  

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

• Трехслойная архитектура применима к различным фреймворкам.  

• Вью может быть тонким клиентом, отображающим данные с сервера.  

• В большинстве случаев лучше использовать все три слоя для полноценного приложения.  

• Адаптер берет данные из модели и модифицирует вью в соответствии с изменениями.  

• Адаптер не передает всю модель, а только необходимые данные для отображения.  

• Бизнес-логика определяет правила, по которым данные могут меняться в приложении.  

• Бизнес-логика определяет, какие действия можно и нельзя выполнять в игре.  

• Примеры: терраформирование земли, покупка ресурсов, перемещение во времени.  

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

• Обсуждение различных паттернов и их реализации.  

• Пример: модель-вью адаптер, где вью публикует события для обновления адаптера.  

• Паттерны упрощают сложные задачи, но имеют разные подходы и реализации.  

• Обсуждение двухслойной архитектуры: модель и вью.  

• Пример: адаптер изменяет вью через ивенты.  

• Важно различать геймплейные и юайные паттерны.  

• Обсуждение геймлейных паттернов и их применения.  

• Пример: MVP и MVVM паттерны.  

• Важно понимать, когда использовать геймлейные паттерны, а когда юайные.  

• MVVM паттерны упрощают взаимодействие слоев в приложении.  

• Пример: вью полностью пассивная, что позволяет избежать сложной логики.  

• Важно учитывать, что MVVM паттерны ограничивают возможности для добавления логики в вью.  

• Обсуждение жизненного цикла объектов и их связывания.  

• В паттерне MVP вьюха и презент привязаны один к одному.  

• Бизнес-логика перемещена в модель, а логика вьюхи стала плоской.  

• Сравнение сложности логики презентации и бизнес-логики.  

• Пример с симуляцией в игре, где бизнес-логика сложнее презентации.  

• Рекомендация выбирать паттерн в зависимости от сложности логики.  

• Порядок создания и связывания вью и презента.  

• Использование фабрики для создания презентера.  

• Обсуждение использования Behaviours 3 для искусственного интеллекта.  

• Использование архитектуры на основе фич или бизнес-компонентов.  

• Разделение модели на отдельные части для разных фич.  

• Важность написания фреймворка для сборки объектов.  

• Оптимизация инициализации и передачи зависимостей.  

• Обсуждение сложности написания фреймворков.  

• Примеры использования разных фреймворков в зависимости от проекта.  

• Возможность использования нескольких паттернов в одном приложении.  

• Пример с гэмблингом и игровой частью, где используются разные паттерны.  

• Преимущества использования разных адаптеров для разных событий.  

• В Unity можно использовать готовые фреймворки, такие как JavaScript.  

• Изучение документации требует усилий, но готовые фреймворки упрощают процесс.  

• Если студия уже имеет готовые фреймворки, их можно использовать повторно.  

• Unity фокусируется на рендеринге, физике и жизненном цикле объектов.  

• Веб-фреймворки предлагают готовые решения для веб-приложений, но Unity требует индивидуального подхода.  

• Unity предлагает множество возможностей, но требует выбора и адаптации под конкретные задачи.  

• Behavoir Tree не подходит для управления игровыми состояниями.  

• Разные инструменты решают разные задачи, и их неправильное использование может быть неэффективным.  

• Важно контролировать и понимать игровые состояния, а не просто использовать их для поведения.  

• Finite State Machines полезны для управления игровыми состояниями.  

• Важно понимать, как состояния начинаются, заканчиваются и что происходит между ними.  

• Behavoir Tree фокусируется на поведении, а не на состояниях.  

• Model-View-ViewModel MVVM отличается от предыдущих паттернов.  

• MVVM предполагает, что вьюха не является интерфейсом, а представляет собой язык разметки.  

• Фреймворк реализует биндинг данных между вьюхой и моделью без необходимости писать дополнительный код.  

• Data Binding позволяет фреймворку связывать данные между вьюхой и моделью.  

• Вьюха может быть языком разметки, который преобразуется в UI.  

• MVVM подразумевает, что модель публикует ивенты, а вьюха подписывается на них.  

• Современные фреймворки используют паттерны, такие как Event Driven.  

• Модель может закрывать сервер и обновлять данные по правилам.  

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

• Простые приложения могут использовать модели без сложной логики.  

• Фреймворки могут автоматически генерировать модели по структуре баз данных.  

• В Unity это требует дополнительных усилий, но возможно.  

• Unity пока не заброшен, но требует развития.  

• Биндинг мог бы быть полезным дополнением для упрощения работы.  

• Важно учитывать стек технологий и особенности проекта.  

• Кастомизация важна для мобильных приложений.  

• Unity позволяет легко создавать анимации, но требует контроля.  

• Важно учитывать особенности проекта и команды.  

• Можно разделять модели на разные ответственности.  

• Это упрощает работу, но требует конвенции в команде.  

• Разделение должно быть обосновано ключевыми ответственностями.  

• UI Toolkit полезен для дизайнеров, но требует доработки.  

• Вопрос о его продакшн-пригодности остается открытым.  

• Рекомендация использовать Mediator для упрощения работы.  

• Биндинг остается важным для связи моделей и представлений.  

• Unity Rex не заменяет биндинг, но помогает с реактивностью.  

• Биндинг требует ручного написания кода, но может быть улучшен.  

• Нет готовых решений для паттернов в Unity.  

• Разные реализации паттернов могут быть более удобными.  

• Рекомендация использовать то, что уже проверено и используется.  

• Использование готовых фреймворков не всегда оптимально.  

• Важно выбирать паттерны, подходящие для конкретной игры.  

• Взаимодействие моделей и геймплея зависит от конкретных требований проекта.  

• Модель может закрывать геймплей, но не всегда.  

• Конкретные решения для конкретных задач могут быть уже готовы.  

• Использование биндинга и других инструментов для упрощения работы.  

• Модель вью адаптирована для биндинга.  

• Иерархия моделей позволяет ссылаться на другие модели.  

• Презентеры и адаптеры не должны ссылаться друг на друга.  

• Современные паттерны взаимодействуют через модели.  

• Модели могут быть общими хранилищами данных.  

• Призыв к подписке на канал и взаимодействию в Twitter.  

• Новые паттерны упрощают поток данных.  

• Пример: паттерн MVVM, который упрощает работу с данными.  

• MVVM использует функциональные языки для упрощения кода.  

• Функциональные языки позволяют создавать более простой код.  

• MVVM в C# использует функции для представления моделей и обновлений.  

• Функциональные языки могут быть полезны для игр и других проектов.  

• Модель в функциональном мире содержит только данные.  

• Мутабельные структуры данных позволяют упрощать код.  

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

• Модели заменяются на новые при изменениях.  

• Операции с неизменяемыми структурами данных оптимизированы.  

• Добавление элементов в однонаправленные списки не требует клонирования.  

• Вью возвращает описание состояния экрана.  

• Месседжи могут быть реакциями на действия или командами для изменения модели.  

• Месседжи могут быть простыми реакциями или командами для изменения модели.  

• Апдейт может создавать новую модель и месседж.  

• Команды могут быть переиспользованы для оптимизации кода.  

• Пример с командой для увеличения здоровья персонажа.  

• Модель и апдейт лучше использовать в функциональных языках.  

• В Unity не рекомендуется использовать модель и апдейт без поддержки функционального программирования.  

• Использование дискриминатов и юнионов в Unity для упрощения кода.  

• Дискриминаторы позволяют выбирать между несколькими вариантами.  

• Юнионы объединяют несколько типов данных в один.  

• Это упрощает описание и поддержку различных типов месседжей.  

• Прописывание обработчиков для нового типа мессенджера.  

• Возможность забыть создать вью при написании нового элемента.  

• Проблемы с компиляцией и необходимость симуляции.  

• Обсуждение различных паттернов и их применимости.  

• Пример с MVVM и его преимуществами.  

• Легкость чтения и использования кода на MVVM.  

• Функциональное программирование как мощный инструмент.  

• Необходимость изучения функциональных языков для полноценного использования.  

• Примеры использования функционального программирования в играх.  

• Навигация как отдельная подсистема фреймворка.  

• Методы для перехода между окнами и их взаимодействие.  

• Важность поддержки кнопки назад в Android.  

• Инфраструктурный код и его роль в навигации.  

• Логика навигации и её влияние на производительность.  

• Примеры использования паттернов для навигации.  

• Вопросы о паттернах и их применении.  

• Пример с вью, кнопкой, хендлером и компонентами на сцене.  

• Продолжение обсуждения и примеры использования паттернов.