Прошло уже лет 25 со дня изобретения концепции Model‑View‑Controller, а споры и её модификации не завершаются по сей день. Хотя очевидно, что в изначальном виде эта концепция ужасна, не объектно‑ориентирована и избыточна. А избыточно именно наличие контроллера, в то время как разделение визуализации и бизнес‑логики является сердцем этой концепции, из‑за чего и живет эта идея до сих пор. Но вопрос контроллера замыливается, хотя понятно, что на его месте должна быть реализация биндинга. Особенно, когда в игровом движке Unity это биндинг уже есть изначально, хотя и появился косвенно. Об этом подробно рассказываю в следующем видео.
0:00 Мы не будем делать полноценное MVC.
1:40 Пример визуализации (View) и задачи.
3:46 Специфика Unity.
5:00 Создание класса визуализации PersonUI и префабов PersonSlot и PersonSlotExt.
12:15 Биндинг реализуется через связь визуальных элементов в префабах со свойствами класса PersonUI.
15:50 Пример создания объекта на сцене через префаб, заполнение свойств класса PersonUI из класс Person, выполняющего роль модели.
17:00 Класс визуализации PersonUI агрегируется в классе модели Person как часть.
18:00 Создаем реакцию на событие нажатия кнопки — метод OnClick().
24:00 В визуальном классе PersonUI создаем событие Click, которое произойдет в методе OnClick() в момент нажатия пользователем на кнопку.
28:00 В невизуальном классе Person создаем метод ViewPersonInfo(), который синхронизирует свойства визуального класса с невизуальным.
37:15 В классе Society (старшая в иерархии модель) агрегируем класс PersonUI, который будет использоваться для разных Person.
45:10 Подписываемся на событие Click в классе Society.
46:40 Добавляем параметр в делегат события, который позволит узнать Id персоны на которой кликнули (нажали кнопку).
54:20 Тестируем, исправляем баги.
1:01:40 Заработало.
1:06:00 Дополнительная доработка, рефакторинг и т. д.
Комментарии (15)
delphinpro
00.00.0000 00:00+13Прихожу на Хабр за текстовым контентом.
tac Автор
00.00.0000 00:00Начните от сюда (это все мои статьи, так или иначе связанные с MVC)
https://habr.com/ru/post/138461/ - Правильное использование паттерна «Мост» (Мост с двухсторонним движением) или MVC->«Бизнес-сущность — Визуализация — Контроллер»https://habr.com/ru/post/219445/ - Где наша бизнес-логика для идеалиста?
https://habr.com/ru/post/668928/ - Как учат создавать игру вида TowerDefence — ошибки «новичков»
https://habr.com/ru/post/670884/ - Когда в Unity нужно MVC, как сделать Binding визуальных контроллов с методом
А затем, я думаю, вам будет полезно посмотреть и прилагающиеся видео, это в том числе - они вас погрузят глубже, чем статьи. Правда не факт, что у вас такая цель. Но для того, чтобы разобраться в теме - это лучше.
isadora-6th
MVC Это замечательная штука и человечество пока не придумало ничего поуниверсальней и получше. И это не про парадигму программирования, а про архитектуру кода (если проще, куда складывать текст, где складывать текст который считает цифры).
MVC он не про объекты, и "ужасна, не объектно-ориентирована и избыточна" это не совсем корректное замечание.
Избыточным контроллер назвать действительно сложно. Основная идея тут в том, что изменения цвета кнопок не протекают в бизнес и наоборот.
Если вы размещаете бизнес логику в UI, то возможно, в процессе развития проекта, вы как-то подозрительно часто будете переписывать с нуля и делать крошечные правки на +1000/-1000, в казалось бы несвязанных моментах.
У вас не получится унести из MVC контроллеры по той простой причине, что без контроллера, модели становятся бессмысленными, остаются только вью, которые могут быть любыми.
То, что вы реализовали контроллеры на биндингах, это замечательно. Интересно посмотреть, вылезет ли проблема отсутствия каста к моделям между слоями и не придется ли при изменении элемента UI, менять биндинг, менять другие связанные элементы, чего бы не было в случае классической реализации MVC.
tac Автор
Или я не понял ваш комментарий, или вы лукавите. Расскажите мне как при изменении элемента UI в MVC ничего не меняется? Если вы добавляете отображение скажем Description.text , то как же не изменится биндинг, если такого свойства вообще раньше не было? А если переименовываете скажем Name в NamePerson - у вас действительно не изменится биндинг и он продолжит синхронизировать не существующие уже свойство Name?
Так какое изменение вы имели введу?
isadora-6th
В классическом MVC, View типы занимаются преобразованием своих штук в модельные типы. Бизнес (который контроллер) принимает и отдаёт только модельные типы.
Если в классическом MVC, у View у вас поменялись имена полей, принцип которым вы достаёте ввод пользователя, и прочие детали реализации, то бизнес скорее всего про изменения не узнает, что есть благо.
Иногда приходится изменять бизнес логику, обработки, что тоже с большой вероятностью не заденет View штуки.
Проблемы всплывают если нужно менять модель. Тут непонятно. Выручают только многослойные модели, с очень маленькой областью применения этих моделей.
Вопрос в том, как безусловно, более короткое решение (на биндингах), покажет себя при изменениях.
tac Автор
т.е. изменения все равно будут, разница лишь в том - где? Только вместо того, чтобы вводить избыточную сущность контроллера, изменения затронут просто вышестоящий в иерархии класс (модель верхнего уровня)
hVostt
Сущность контроллера не избыточна.Это точка размещения кода для взаимодействия UI с логикой, которая кроме того, что позволяет тестировать обе части отдельно, но и позволяет сглаживать различия в представлениях. Например, в логике у вас иерархическая структура, а UI нужна плоская, или денормализованная по полям. Ну и кто должен заниматься этим, если мы пнули под зад контроллер? Правильно понимаю, что теперь слой бизнес-логики должен обслуживать все причуды и потребности UI? А если у нас 2 совершенно разных представления? Например, UI и публичные API. Под кого должна затачиваться бизнес-логика?
Совершенно правильная идея, выкинуть избыточные вещи. Но контроллер к ним не относится.
tac Автор
Да, задача бизнес логики решать через какое UI работать в том или ином случае. И делает это вышестоящий в иерархии класс. Несмотря на ваши общие тезисы без примеров, я их могу привести. Например, класс Society в моем примере будет решать в зависимости от поведения игрока, показать ему информацию о персоне упрощенно, или подробно. Да, именно он настроит это вместо избыточного контроллера.
hVostt
Если вы убрали из класса, выполняющего функции слово "Controller", и сказали -- вот мы избавились от контроллера, и теперь это "вышестоящий в иерархии класс", это не более чем самообман. В качестве аналогии, магазин решил избавиться от лишней сущности "курьер", уволил всех курьеров, и нанял ровно столько же продавцов, потому что теперь они выполняют функции курьера. Теперь это и не продавец и не курьер, а просто "какой-то класс в иерархии", который не понимает в какой области ему сосредоточить усилия, так как требования остались те же самые. Вот так, люди совершенно наивным способом зачастую от чего-то там "избавляются", а потом трубят об этом, словно сделали великое открытие. Ведь остальное человечество глупые, наделали каких-то лишних сущностей и теперь страдают :)
tac Автор
Вы упорствуете в своем невежестве. Хорошо. Вот вам просто мои статьи на этот же вопрос, когда вы под стол пешком ходили. https://habr.com/ru/post/138461/
https://habr.com/ru/post/670884/
https://www.youtube.com/watch?v=joEGQ_Lb14M
думаю вы там мало чего поймете, но это статьи когда и как нужно использовать MVC
это статья о том когда не нужно.
И еще есть видео, во что превращается код, когда такие как вы не понимают когда, нужно и когда не нужно
https://www.youtube.com/watch?v=QYNaaxkfH-Y&t=30s
upd. внезапно, прошел по первой ссылке и увидел, что еще и тогда, вы так и не понимали ничего о контроллерах, читая мои статьи на этот счет, думаю - это проф. не пригодность. Но теперь у вас есть больший выбор, с того времени я для таких написал и снял разные вариации, чтобы они хотя бы немного поняли бы границы применения MVC. Успехов!
togokode
На хабр приходят читать, а не смотреть. А вы видосик предлагаете. Это так же невежественно как в чат на войсе заходить. Количество дизов не удивительно. Удалите это, не позорьтесь. И напишите нормальную статью.
tac Автор
Правилами не запрещено, но в формате статьи так подробно не получится донести, поэтому привыкайте. Будет интересовать действительно тема, а не промотать по диагонали - послушаете, а нет проходите мимо. Мало ли чего вы там хотите, у меня вот в таком формате, таймкоды дал.
А то, что тут неадекватно оценивают - так это не новость, хабратушканчиков давно знаю :)
hVostt
У вас настолько же хорошо развито хамство, как и невежество в теме, на которую снято ваше видео. Эти качества, обычно, идут рука об руку.
tac Автор
Наверно, если у вас нет, что конструктивно сказать - это уже показатель. Советую, лишь читать и слушать - независимо от формата, что говорят взрослые дяди, такие как я и не перечить старшим. Это не вам должно быть удобно, а мне ...
а проблема того, что хабр давно стал токсичным местом, увы, не моя ... но именно такие как вы делают в это большой вклад, но большая ответственность конечно на владельцах.