не могу понять, как должна выглядеть правильная реализация вот такого варианта. При запуске приложения во вью 2 поля ввода, пользователь вводит данные(не авторизация) и по Ок переходит на следующую вью, там уже привязана к VM и пользуется данными полученными ранее. Не понимаю, как должна выглядеть передача данных, чтобы никто толком не знал друг о друге. Читал про локатор и мессенджер, но мессенджер вроде как слишком сильная связь. Возможно локатор это то что мне требуется, но не уверен. И ещё, не очень понимаю, в принципе у меня будет только одна модель в проекте, нужно ли для стартовой вью создавать отдельную модель которая будет просто дублировать нужные поля из основной модели?
Vm нужна либо для каждой вью, либо одна на обе, для передачи данных можешь создать промежуточную Vm которую унаследуешь в остальных Есть много вариантов обвязок, и знание одной Vm о другой не нарушает Mvvm Mvvm отвязывает логику BLL от View
И главное в мввм - CodeBehind плохой подход на любом этапе разработки
Если ты вообще только начал, то на ранних этапах разработки инициализация одной vm в другой не будет плохим тоном, потом можешь тренироваться с иными способами, автофак и тд
Да, только начал, пока 2 проекта маленьких сделал, но там все в одну вью укладывал, или вызывал дочерние(меню -> окно пункта меню), но там писал "типа" диспетчера окон и ни о какой передаче данных не шла речь,
а все таки, вне зависимости от того, только начал или нет, как будет правильнее такое организовать, мне не хочется учиться на плохой практике, хочется как надо, пусть и путь будет сложнее =)
Я делаю единый ViewModelBase в котором реализация INotifyPropertyChanged и всякие свойства которые являются общими для нескольких VM, базовый Vm нужно регать в автофаке как синглтон и от него наследовать все VM
Ещё можно обвязать дополнительно NotificationPipes, это реализация паттерна Observer, удобно вешать триггеры и ловить изменения свойств
я вот еще читал, мне показалось уместным воспользоваться паттерном Mediator, я так понимаю, что они очень схожи, но по описанию он как раз то что нужно, дает слабую связь, и пишут, что многие фреймворки берут именно его за основу. Но в любом случае, это самый верный подход, некая сущность, которая связывает в себе все остальное?
Да, хорошая штука
NotificationPipes то же самое, по сути, ты прослушиваешь определенную точку (метод, свойство) в нем, а кто-то пушит в эту точку какие-либо данные, или просто вызывает. Соответственно подписчик будет ловить этот триггер
Спасибо большое, теперь понятно в какую сторону копать =) буду теперь разбираться в правильной реализации =)
Обсуждают сегодня