История изменений
Исправление slackwarrior, (текущая версия) :
Пошагово объясните как должен работать этот сервис.
*Затягивается донским табаком*
Не знаю, как должен, а обычно они работают как-то так: сервис получает какой-то ключ, по которому будет искать нужную вьюмодель. Это может быть енум, токен типа, Type class, интерфейс — кому как удобнее. Мазохисты создают сервис на каждый чих. И потом сами не помнят где что. У этого конкретного сервиса под капотом обычно есть какой-то «фабричный» (ТМ) способ поиска («ни в коем случае не локации!» :)) цели для захардкоженного (раннего)... или позднего... или «на ходу» связывания. Т.е. свич из Typeов вьюх в вызовы оператора new для вьюмоделей, словарь экземпляров, словарь террористов для взрывов на фабрике вьюмоделей.
В «самый моменд О» (обнаружения, ни в коем-случае не локации!) нужного способа, этот сервис дергает... другой сервис, который знает «как», а тот возвращает экземпляр нужной вьюмодели в качестве контекста для вьюхи.
Вся эта канитель может в простейшем случае быть захардкожена как свич заранее созданных экземпляров (завернутых в интерфейсы (чтоб никто не догадался)), либо вьюмодели только «регаются» как «возможности» (через ссылки на сервисы, хэндлеры, фабрики).
При этом надо учитывать, что MVVM как «паттерн разделения» справляется «болиемение» именно с разделением — как потом общаться разделенным экземплярам в абстрактных примерах объясняют редко (для этого решают собственноручно созданные проблемы добавлением «шины сообщений» и прочие «подписки» на спрятанный под семь слоев абстракций визитор с локатором).
Вью-модели таким образом могут создаваться на лету — для юзера это неотличимо от «открытия окна». И только модели, которые живут дольше всех, знают, какая на самом деле шляпа под капотом :)
Исходная версия slackwarrior, :
Пошагово объясните как должен работать этот сервис.
*Затягивается донским табаком*
Не знаю, как должен, а обычно они работают как-то так: сервис получает какой-то ключ, по которому будет искать нужную вьюмодель. Это может быть енум, токен типа, Type class, интерфейс — кому как удобнее. Мазохисты создают сервис на каждый чих. И потом сами не помнят где что. У этого конкретного сервиса под капотом обычно есть какой-то «фабричный» (ТМ) способ поиска («ни в коем случае не локации!» :)) цели для захардкоженного (раннего)... или позднего... или «на ходу» связывания. Т.е. свич из Typeов вьюх в вызовы опратора new для вьюмоделей, словарь экземпляров, словарь террористов для взрывов на фабрике вьюмоделей.
В «самый моменд О» (обнаружения, ни в коем-случае не локации!) нужного способа, этот сервис дергает... другой сервис, который знает «как», а тот возвращает экземпляр нужной вьюмодели в качестве контекста для вьюхи.
Вся эта канитель может в простейшем случае быть захардкожена как свич заранее созданных экземпляров (завернутых в интерфейсы (чтоб никто не догадался)), либо вьюмодели только «регаются» как «возможности» (через ссылки на сервисы, хэндлеры, фабрики).
При этом надо учитывать, что MVVM как «паттерн разделения» справляется «болиемение» именно с разделением — как потом общаться разделенным экземплярам в абстрактных примерах объясняют редко (для этого решают собственноручно созданные проблемы добавлением «шины сообщений» и прочие «подписки» на спрятанный под семь слоев абстракций визитор с локатором).
Вью-модели таким образом могут создаваться на лету — для юзера это неотличимо от «открытия окна». И только модели, которые живут дольше всех, знают, какая на самом деле шляпа под капотом :)