Почему всегда, когда заходит речь о загрузке ассетов, например через

Addressables, упорно игнорируется наличие слабой ссылки в виде AssetReference? Я даже видела проекты в продакшене, где используются Addressables, но грузится по имени/пути, что дает очень много попаболи 😃

Допустим, есть презентер UI, который получает ссылку на представление в виде монобеха / GO. Презентер это ванильный класс. В него ты не положишь AssetReference, т.к. нет сериализации. В таком случае удобно иметь компонент и GO с одним именем и загружать представление напрямую из бандла через nameof.

Геймдизайнер будет ненавидеть вас за такое)

а причем здесь геймдизайнер?

При том, что заменить view не получится одним кликом, а надо лезть в код. В вашем примере я вижу как минимум несколько проблем: - неизменяемость view (имею в виду, что нельзя подставить другую реализацию) - изменение имени префаба ломает логику - изменение имени класса ломает логику

а как этот AssetReference задавать скажем в гугл таблице

Всегда можно сопоставить читаемое имя в гугл таблице и guid, который хранится в AssetReference, это вопрос импорта/экспорта уже

ну тут либо правило сопоставления нужно либо еще одна таблица/словарь тогда

вот это не вижу как решает эту же проблему если честно

Каким образом гдшник может поменять представление через AssetReference, не залезая в код / префаб? Он должен выполнять задачу программиста? Тогда тут действительно организационный вопрос, а не архитектурный, по какой причине обязанности перекрываются. Далее едем. Замена контента в префабе, находящемся в бандле, при сохранении имени класса и префаба не сломает абсолютно ничего. Именно так и работает подмена представления, потому что интерфейс (речь про код, а не гуй) остается на месте. Если же логика нарушилась, значит программист не отделил должным образом модель и неправильно сделал презентер. Опять же, это не является проблемой загрузки через строку.