Как организовать иерархию папок в Unity при использовании MVx паттернов?
Я планирую создать небольшой проект для портфолио и использовать там MVP паттерн. До этого я никогда не использовал никаких архитектурных паттернов. Вопрос состоит в том, как организовать иерархию папок и скриптов в Unity. Нужно ли делать жесткое разделение папок с Model, View и Presenter? И нужно ли в названии скрипта добавлять суффиксы Model, View и Presenter? Заранее всем спасибо.
Ответы (1 шт):
MVC... MVP... MVVM... не важно! Model, она и в африке Model, а View и на марсе View, это категории сущьностей, существующие сами по себе, а не только в рамках этих шаблонов по их взаимодействию.
Если у тебя есть FooModel и FooView то сущность, которая их объединяет это бизнес-логика и она не нуждается в спецификациях и обозначениях.
Если ты что-либо назовёшь ...Controller или ...Handeler, то в 99 случаев из 100 они используются как имена-паразиты и это уже -100^2 в карму. В этих 99 случаев программист сам не понимает, в чём конкретно ответственность класса и не может дать ему отражающее эту ответственность имя, привет Single Responsibility. Всегда важен контекст, одно и то-же имя в разных случаях может быть как конкретным, так и размытым.
View? Который View? Какие-нибудь UnitSkin, UnitBar и UnitLayout, это всё является View, но один отвечает за модельку с анимациями, второй за UI в виде HP и MP над головой, а третий за UI с иконкой, именем и ещё какой ни-будь инфо с краю экрана. Cлова Skin, Bar и Layout уже сами по себе говорят о визуализации и добавление View, делает масло масляным, банальная тавтология.
...View добавляется в строго однозначных ситуациях, когда контекст всего один. Например InventoryItem и InventoryItemView. А на игровой сцене валяются всякие хилки, PowerUpы, патроны , все наследники абстракции CollectableItem, которые обрабатывает UnitCollector и есть CollectableInventoryItem содержащий наш InventoryItem. Все наследники CollectableItem это носители разных данных, но логика визуала у них одиа и та-же, это обычное состояние и анимация/звуки подбора и класс для этого может быть всего один CollectableItemView, либо некоторые используют свой, но опять-же наследуются от основного, как девиация.
...Model добавляется часто, также может быть ...Data, смысл один, там только модель данных, без бизнес логики. Но опять-же это не обязательно, могут быть говорящие названия, подразумевающие только данные. Например у тебя классическая аркада и в конце сессии тебе показывают: время, количество собранных монет, количество убитых врагов и это хранится в struct GameRecord или SessionRecord и у неё даже есть свой View и никакая Model или Data в названии ему нахрен не нужны. Если данные не зависимы и самодостаточны, то никакой Model в имени им не обязателен, а тип struct в C# сам по себе говорит о том, что это данные. Даже в рамках вышеупомянутых шаблонов, могут быть модели, обработчики и визуализация с разными именами, типа продукция/склад/магазин.
Каталогизация должна быть понятной и последовательной, не важно какой, лишь бы не мусорка, где чёрт ногу сломит и хер чё найдёшь. Папка Model понятна, если объект состоит из большого количества моделей данных, как при ECS архитектуре или есть много View, например абстрация + парочка наследников, так проще ориентироваться, но если у тебя всего 2,3, 5... классов, то зачем нужны 2-3 папки по 1-2 файла? Если какие-нибудь юнит-тесты всегда помещать в отдельную папку Test, даже если это один файл выглядит нормально, но в остальных случаях фигня какае-то. Суть каталогизации в удобстве листинга файлов, если файлов много, удобнее с категориями, если мало, удобнее без них.