MVVM и INotifyPropertyChanged

@Sirius1989 · Регистрация: 07.01.2017

Студворк — интернет-сервис помощи студентам

Здравствуйте. Начал разбираться с MVVM. И для меня непонятно в каких случаях нам нужно наследовать интерфейс INotifyPropertyChanged в model и в viewmodel, а в каких только в viewmodel?

@Элд Хасп · 27.08.2019, 21:43

Сообщение от Sirius1989

Начал разбираться с MVVM. И для меня непонятно в каких случаях нам нужно наследовать интерфейс INotifyPropertyChanged

WPF View получает данные из VM в основном через привязки к свойствам.
Здесь возникает вопрос - при создании привязки из свойства было сосчитано значение и оно было отображено. А если значение изменилось, то как View об этом узнает?
DP-свойства содержат механизм уведомления о изменении значения. А обычные свойства такого механизма не имеют.

Для отслеживания изменения значений обычных свойств используется INPC. Поэтому все свойства VM предназначенные для привязки в View должны ОБЯЗАТЕЛЬНО уведомлять об изменении своих значений через INPC.

Модели тоже возникает похожая ситуация. Но там нет уже обязательного условия использования INPC. Можно использовать другие механизмы и события. Но INPC широко распространён, прост в использование, легко адаптируем - поэтому часто, особенно в простых случаях, используют его и в Модели.

Прочитайте темы из Готовые решения, примеры и рекомендации начинающим на WPF [Элд Хасп], в том числе "INPC и получение данных из Модели"

@novikov.ea · 28.08.2019, 13:30

Сообщение от Элд Хасп

поэтому часто, особенно в простых случаях, используют его и в Модели

Честно говоря, кроме ваших примеров, я более нигде не видел, чтобы INPC использовался в модели. INPC в слое модель, безусловно, можно использовать, так как INPC - это не платформозависимый интерфейс. Однако, не могу согласиться с утверждением, что INPC используется в модели часто. Скорее, редко, так как INPC не даёт чёткого контракта взаимодействия с моделью с точки зрения оповещения ViewModel о наступлении любых событий. PropertyChanged не подходит для данной роли. Гораздо проще оперировать конкретными событиями, дающими понятный контракт взаимодействия. Например: StatusChanged, Locked, AuthenticationCompleted. А событие PropertyChanged нужно использовать лишь тогда, когда необходимо уведомлять клиента о событиях изменения значения свойств (причём любых свойств).

Сообщение от Sirius1989

в каких случаях нам нужно наследовать интерфейс INotifyPropertyChanged в model

Главный вопрос в том, какую задачу вы решаете. И нужно ли для решения этой задачи действительно уведомлять ViewModel об изменениях значений свойств. Если в этом нет необходимости, то не нужно реализовывать INotifyPropertyChanged в Model. А делать это специально не имеет смысла. За 8 лет работы с WPF я ещё не сталкивался с реальной необходимостью реализации интерфейса INotifyPropertyChanged на уровне Model.

@Sirius1989 · 28.08.2019, 13:36 **[ТС]**

novikov.ea, в моём случае изменяются свойства модели, поэтому мне необходимо уведомлять об этом ViewModel, чтобы в дальнейшем обновить View. Кроме как реализовывать INotifyPropertyChanged в Model, других лучших способов я не знаю, если вы знаете, напишите, пожалуйста, если можно с примерами.

@novikov.ea · 28.08.2019, 13:45

Model имеет какую-либо логику? Или ваши объекты ViewModel просто полностью дублируются объектами Model? Что делает приложение?

@Sirius1989 · 28.08.2019, 13:49 **[ТС]**

novikov.ea, в Model у меня имеется метод в классе, который в цикле производит итерацию над одним из свойством этого класса, и мне нужно, чтобы во View при итерации данного свойства происходила итерация значения ProgressBar.

@novikov.ea · 28.08.2019, 14:13

Сообщение от Sirius1989

над одним из свойством этого класса

У вас изменяется только одно свойство в модели. Для уведомления ViewModel о том, что значение счётчика изменилось, достаточно создать одно событие CounterChanged. С помощью него и будет происходить уведомление ViewModel со стороны Model

Пример кода.

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
public class CountEventArgs : EventArgs
{
    public CountEventArgs(int count)
    {
        Count = count;
    }
    
    public int Count { get; }
}
 
public class MyModel
{
    private bool _isRunning;
    private int _counter
    
    public event EventHandler<CountEventArgs> CounterChanged;
    
    private void RaiseCounterChanged()
    {
        CounterChanged?.Invoke(this, new CountEventArgs(_counter));
    }
    
    public async Task Start()
    {
        if (_isRunning)
        {
            return;
        }
        
        _isRunning = true;
        while (_isRunning)
        {
            await Task.Delay(1000);
            _counter++;
            RaiseCounterChanged();
        }
    }
    
    public async Task Stop()
    {
        _isRunning = false;
    }
}
 
public class MyViewModel : ViewModelBase
{
    public MyViewModel(MyModel model)
    {
        model.CounterChanged += OnCounterChanged;
    }
    
    private int _counter;
 
    public int Counter
    {
        get { return _counter; }
        set { SetProperty(ref _counter); }
    }
    
    private void OnCounterChanged(object sender, CountEventArgs e)
    {
        Counter = e.Count;
    }
}

@Элд Хасп · 28.08.2019, 14:26

Сообщение от novikov.ea

Честно говоря, кроме ваших примеров, я более нигде не видел, чтобы INPC использовался в модели.

Да - я грубанул.
"Часто" - в учебных примерах. По началу когда осваивал WPF+MVVM смотрел разные примеры, видеоуроки практически всегда в Model использовался INPC. Это связано с тем, что в таких локальных приложениях передача данных от Model происходит в типах которые потом напрямую отображаются в View и, соответственно, в этих типах обязательно реализуется INPC. НО так как в типах данных Модели есть реализация INPC, то логично и в самой Модели делать такую реализацию.

В приложениях же где нет прямой передачи данных в оригинальных типах (это практически все крупные и нелокальные приложения), там, конечно, использование INPC хоть и возможно, но другие механизмы оказываются более эффективными.

Что же касается

INPC не даёт чёткого контракта взаимодействия с моделью с точки зрения оповещения ViewModel о наступлении любых событий

, то INPC легко адаптировать. Делается производный класс от PropertyChangedDataEventArgs добавляются в него свойства и получаем возможность передачи дополнительной информации. В разделе есть тема где я в примере использую подобное.

Добавлено через 2 минуты

Сообщение от novikov.ea

Model имеет какую-либо логику? Или ваши объекты ViewModel просто полностью дублируются объектами Model? Что делает приложение?

Посмотрите соседнюю тему от Sirius1989 ProgressBar в MVVM

@novikov.ea · 28.08.2019, 14:36

Сообщение от Элд Хасп

НО так как в типах данных Модели есть реализация INPC, то логично и в самой Модели делать такую реализацию

Непонятно, чем в данном предложении "тип данных Модели" отличается от "самой Модели". И что вы называете "оригинальным типом"?

Сообщение от Элд Хасп

в таких локальных приложениях передача данных от Model происходит в типах которые потом напрямую отображаются в View и, соответственно, в этих типах обязательно реализуется INPC

Если модель напрямую отображаются в View и при этом должна уведомлять о своих изменениях, то это уже не модель, а ViewModel.

@Элд Хасп · 28.08.2019, 15:27

Сообщение от novikov.ea

Если модель напрямую отображаются в View и при этом должна уведомлять о своих изменениях, то это уже не модель, а ViewModel.

Да.
Где-то в разделе есть тема с обсуждением этого.

Допустим, есть клиент-серверное приложение: какой-то сервер отправляет ответы на запросы. Запросы и ответы в JSON.

Наша задача создать клиента. В клиенте мы выделяем Модель для работы с сервером и отправки/получения сообщений.
После парсинга JSON получаем типы которые отправляем по цепочке Model->VM->View. В этих типах нужна реализация INPC.
И Модель Клиента - это Локальная Модель, которая, по сути, является частью VM. Сама же Model - это сервер, так как вся бизнес логика находится там.

Но в простых локальных приложениях, особенно в созданных с учебной целью, кроме этой локальной Модели и нет другой. Так же как и в задаче от Sirius1989.

Я не сколько не спорю с вами по сути. Просто в своих вопросах Sirius1989 интересуется за такую Локальную Модель, которая, как вы справедливо заметили, на самом деле и не Модель, а часть VM.

@Элд Хасп · 28.08.2019, 15:55

Сообщение от novikov.ea

"тип данных Модели" отличается от "самой Модели"

Может я неправильно выразился - с терминологией плохо знаком.

На примере Программное заполнение коллекции и отображение в DataGrid с использованием MVVM пост #14.

Модель - это class ModelMVVMTest.
Тип для передачи данных - это class Person.

@novikov.ea · 28.08.2019, 16:21

Сообщение от Элд Хасп

В этих типах нужна реализация INPC

Зачем?

Сообщение от Элд Хасп

И Модель Клиента - это Локальная Модель, которая, по сути, является частью VM

Неправда. Если в клиентском приложении существует логика отправки запросов на сервер и обработка получения ответов, то эта логика никак не связана с логикой отображения ответа в GUI. Значит, данная логика никак не может быть отнесена к уровню ViewModel. Просто потому что это не является моделью представления.

Сообщение от Элд Хасп

Сама же Model - это сервер

Почему? Разве в клиентском приложении не существует никакой логики, не относящейся к отображению информации? Пусть даже если все алгоритмы находятся на сервере, существует функционал, который может существовать в клиентском приложении и не будет являться частью логики отображения данных:
1) Отправка запросов на сервер и их обработка
2) Логирование
3) Работа с локальной БД (например, для кэширования)
4) Обращение к файловой системе клиентского компьютера
5) Получение системного времени клиентского компьютера

Это всё логика уровня Model, но никак не ViewModel, так как данная логика не имеет никакого отношения к модели представления.

@Элд Хасп · 28.08.2019, 16:43

Сообщение от novikov.ea

Зачем?

А как иначе отлавливать изменения в свойствах типа?

Допустим, по ответу создали new Person() {Id =1, Name="Ivan"};
Теперь, приходит сообщение об изменении Name у Id=1. Если есть INPC, то мы находим Person с этим Id и меняем имя.
А если нет INPC?

Ответ от Storm23 в теме Классы Model в View

Цитатау вас тонкий клиент, то есть логика вся на сервере, то локальная модель это тоже самое что ViewModel, потому что она не содержит никакой логики и единственная ее цель - это взаимодействие с интерфейсом пользователя

Сообщение от novikov.ea

Неправда. Если в клиентском приложении существует логика отправки запросов на сервер и обработка получения ответов, то эта логика никак не связана с логикой отображения ответа в GUI.

В VM ВСЕГДА есть логика по отправке и получению данных в Модель.

@novikov.ea · 28.08.2019, 17:04

Сообщение от Элд Хасп

какой-то сервер отправляет ответы на запросы. Запросы и ответы в JSON

Сообщение от Элд Хасп

После парсинга JSON получаем типы

Эти типы являются простыми DTO. Для чего им INPC?

Сообщение от Элд Хасп

Теперь, приходит сообщение об изменении Name у Id=1. Если есть INPC, то мы находим Person с этим Id и меняем имя.
А если нет INPC?

А без INPC невозможно уведомлять ViewModel о наступлении событий?
С сервера приходит сообщение об изменении Name у Id=1. Класс уровня Model, обрабатывает это и инициирует событие, например, PersonChanged с информацией Id=1. ViewModel, подписавшись на это событие, получает уведомление о его наступлении и изменяет данные для отображения.
Никакой INPC для того, чтобы это реализовать, не потребовался.

Сообщение от Элд Хасп

есть логика вся на сервере, то локальная модель это тоже самое что ViewModel, потому что она не содержит никакой логики и единственная ее цель - это взаимодействие с интерфейсом пользователя

Не могу согласиться с формулировкой, что локальная модель это тоже самое что ViewModel. Если думать о том, что локальная модель - это ViewModel, то это может привести к нарушению уровней абстракции. Классы, не содержащие логику для подготовки данных для отображения не являются ViewModel. Примеры такой логики я привёл выше.

Сообщение от Элд Хасп

В VM ВСЕГДА есть логика по отправке и получению данных в Модель.

ViewModel общается с Model, вызывая её методы и изменяя её свойства. Model общается с ViewModel через события. Почему же для этого нужно использовать именно INPC?

@titan4ik · 28.08.2019, 21:43

novikov.ea,
спасибо за ваши сообщения в данной теме и раз уж такая пьянка, то вопрос и предложение:
1. По каким материалам лучше всего изучить практические современные варианты реализации паттерна MVVM?
Не хочется проходить весь исторический путь - ранее было одно, сейчас несколько иное и т.д.
P.S.1. И ещё, выходит, что "для примеров", как пишут тут, используется одно, а реально потом нужно будет использовать другое. Вот такой подход, на мой непросвещенный в MVVM взгляд, глубочайшая методологическая ошибка.
2. novikov.ea, хорошо бы, чтобы Вы открыли новую тему и четко дали там один или несколько (для характерных случаев) вариантов практической реализации паттерна MVVM. Тогда их можно было бы использовать как рабочие шаблоны. Меньше было бы вопросов по теме и это дало бы Вам в реальную карму много плюсов)))
P.S.2. Было бы классно, если бы примеры кода Вы сопроводили кратким описанием используемых средств и механизмов и пояснением, почему так, а не эдак.

Добавлено через 26 минут
ПыСы. Бу-га-га

, прям в тему: Паттерн mvvm

@Элд Хасп · 29.08.2019, 00:03

Сообщение от novikov.ea

Почему же для этого нужно использовать именно INPC?

Я и не пишу что для этого НУЖНО INPC.
Я пишу, что для простых, маленьких приложений часто удобно использовать.
Его можно легко адаптировать под конкретное применение. Он прост и широко известен.

Я не сколько не спорю с тем, что для крупных приложений его не имеет смысла использовать.

Речь идёт только о маленьких (в основном учебных) решениях.
По указанной выше ссылке ProgressBar в MVVM можно создать кучу кастомны событий в Модели. Но смысл какой? Просто для того что бы это было не INPC? INPC в указанной задачи прекрасно справляется и ни какого смысла в создании кастомных событий я не вижу. Так же и в большинстве подобных задач. Если INPC справляется и им удобно пользоваться, то зачем создавать кастомные события?

@Элд Хасп · 29.08.2019, 00:23

Сообщение от novikov.ea

Если думать о том, что локальная модель - это ViewModel, то это может привести к нарушению уровней абстракции. Классы, не содержащие логику для подготовки данных для отображения не являются ViewModel. Примеры такой логики я привёл выше.

Получение текстовых данных (txt, JSON, XML, ini и т.д.) и их парсинг в удобные для View типы это чья функция?

Если делать с полной абстракцией уровней в MVVM, то Модель должна получить данные, распарсить их максимум в дефолтные типы (string, int. double и т.п.) и послать сообщение в VM о том, что появились некие данные. VM получает их и по ним создаёт/изменяет типы предназначенные для View в которых, естественно, есть INPC.

Но какой смысл в таком полном разделении? Если Модель может сразу распарсить данные в нужные для View типы? Чем мешает наличие INPC у типов в которые Модель будет парсить данные? А если Модель парсит данные в типы пригодные для View то что это: Model или часть VM?

Я не думаю, что надо отстаивать до фанатизма идею абсолютной чистоты MVVM, тем более что критериев этой чистоты нет и спорить об этом можно до бесконечности.

Да - есть паттерн, есть понимание его реализации, есть какие-то определённые критерии которые желательно соблюдать.
Допустим, для Модели и View это независимость друг от друга. В Локальной Модели создаются типы используемые напрямую в View. Поэтому полностью независимыми Модель и View назвать нельзя. И в таком случае Модель частично выполняет функции VM. Но означает ли, что так строго запрещено делать? Если это удобно, прозрачно, читаемо - то почему бы так не сделать? Только из-за боязни нарушить кристальную чистоту MVVM?

@titan4ik · 29.08.2019, 10:55

Сообщение от Элд Хасп

Да - есть паттерн, есть понимание его реализации, есть какие-то определённые критерии которые желательно соблюдать.
Допустим, для Модели и View это независимость друг от друга. В Локальной Модели создаются типы используемые напрямую в View. Поэтому полностью независимыми Модель и View назвать нельзя. И в таком случае Модель частично выполняет функции VM. Но означает ли, что так строго запрещено делать? Если это удобно, прозрачно, читаемо - то почему бы так не сделать? Только из-за боязни нарушить кристальную чистоту MVVM?

Некомпетентно замечу.
Наверное, аналогично можно "оправдать" любое отступление от того или иного паттерна. Такое ощущение, что этого лучше не делать. Почему? Да по тем именно причинам, по которым эти паттерны и были предложены. Паттерн, в частности - это ж экономия мышления, ограничитель неуемного творчества и локальной квазиоптимизации.
Я сделал в формате "для сэбэ" достаточно объемное (но простое в программистском смысле) приложение инженерное, в котором изначально стал нарушать все паттерны и все принципы ООП))) К концу работы уже стал стараться соответствовать хоть чему-то. Опыт!))) А если буду что-то новое лепить, то постараюсь насколько смогу соответствовать принципам и паттернам) Оно того стоит.

@Элд Хасп · 29.08.2019, 11:31

Сообщение от titan4ik

Некомпетентно замечу.

Ещё раз пишу - посмотрите приложение в теме ProgressBar в MVVM
Какой смысл в использовании кастомного события вместо INPC?

Приложение здесь Программное заполнение коллекции и отображение в DataGrid с использованием MVVM
Какой смысл парсить (десериализовывать) данные в типы без INPC и потом в ViewModel их преобразовывать в типы с INPC?
Чем мешает Модели INPC в Person?

Сообщение от titan4ik

Наверное, аналогично можно "оправдать" любое отступление от того или иного паттерна.

Где хоть в одном источнике написано, что использование INPC в Модели нарушает MVVM?
Где хоть в одном источнике написано, что парсинг данных в Модели в типы пригодные для View нарушает MVVM?

К Модели по сути одно требование - работа с данными не зависимо от используемой View. Посмотрите в Программное заполнение коллекции и отображение в DataGrid с использованием MVVM - там с Моделью работает консолька. Можно использовать и WPF и WF и что другое в голову взбредёт. Так что никакого нарушения MVVM в такой реализации нет.

Добавлено через 10 минут

Сообщение от Элд Хасп

Только из-за боязни нарушить кристальную чистоту MVVM?

Это я пишу не в премом смысле, что такие методы нарушают MVVM.
Выше я уже объяснял, что нет критериев "кристальной чистоты" MVVM. Это дополнительные критерии создаваемые уже различными сообществами программистов или отдельными программистами. И эти критерии могут различаться. Что для одного является "кристально чистым" MVVM для другого может таким не являться.

Поэтому, в начале обучения, я вижу смысл в ориентировании на базовые принципы MVVM, а они предлагают довольно широкую трактовку и различные реализации.

Другое дело, что когда будет работа в каком-то коллективе над каким-то общим проектом, то там появятся дополнительные корпоративные требования, в том числе по реализации MVVM. Допустим, создавать в Prism, MVVMLight и др.
НО это ДОПОЛНИТЕЛЬНЫЕ требования. И в реальной работе их тоже надо исполнять. Но я пишу у БАЗОВЫХ принципах MVVM

@titan4ik · 29.08.2019, 11:52

Сообщение от Элд Хасп

Где хоть в одном источнике написано, что парсинг данных в Модели в типы пригодные для View нарушает MVVM?

Нигде такого не написано.
Но везде пишут, что данные в View попадают из ViewModel.
Поэтому с точки зрения своей некомпетентности, в данном случае я бы дублировал эти типы модели в ViewModel. Локально это не оптимально. Но глобально такой подход может быть правильным. Я не знаю. Пусть гуру выскажутся.
Это же удобно в конце концов - когда все типы данных, которые отображаются в View, определяются в ViewModel.
А в модели полно и других типов.

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .
Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

MVVM и INotifyPropertyChanged

Решение

Решение

@Sirius1989 0 / 0 / 0 Регистрация: 07.01.2017 Сообщений: 47

	WPF MVVM и INotifyPropertyChanged 27.08.2019, 21:43. Показов 7543. Ответов 27 Метки нет (Все метки) Здравствуйте. Начал разбираться с MVVM. И для меня непонятно в каких случаях нам нужно наследовать интерфейс INotifyPropertyChanged в model и в viewmodel, а в каких только в viewmodel? 0

@Sirius1989 0 / 0 / 0 Регистрация: 07.01.2017 Сообщений: 47
	28.08.2019, 13:36 [ТС]
	novikov.ea, в моём случае изменяются свойства модели, поэтому мне необходимо уведомлять об этом ViewModel, чтобы в дальнейшем обновить View. Кроме как реализовывать INotifyPropertyChanged в Model, других лучших способов я не знаю, если вы знаете, напишите, пожалуйста, если можно с примерами. 0

@novikov.ea 1857 / 1363 / 429 Регистрация: 10.06.2011 Сообщений: 2,136
	28.08.2019, 13:45
	Model имеет какую-либо логику? Или ваши объекты ViewModel просто полностью дублируются объектами Model? Что делает приложение? 0

@Sirius1989 0 / 0 / 0 Регистрация: 07.01.2017 Сообщений: 47
	28.08.2019, 13:49 [ТС]
	novikov.ea, в Model у меня имеется метод в классе, который в цикле производит итерацию над одним из свойством этого класса, и мне нужно, чтобы во View при итерации данного свойства происходила итерация значения ProgressBar. 0

@titan4ik Заблокирован
	28.08.2019, 21:43
	novikov.ea, спасибо за ваши сообщения в данной теме и раз уж такая пьянка, то вопрос и предложение: 1. По каким материалам лучше всего изучить практические современные варианты реализации паттерна MVVM? Не хочется проходить весь исторический путь - ранее было одно, сейчас несколько иное и т.д. P.S.1. И ещё, выходит, что "для примеров", как пишут тут, используется одно, а реально потом нужно будет использовать другое. Вот такой подход, на мой непросвещенный в MVVM взгляд, глубочайшая методологическая ошибка. 2. novikov.ea, хорошо бы, чтобы Вы открыли новую тему и четко дали там один или несколько (для характерных случаев) вариантов практической реализации паттерна MVVM. Тогда их можно было бы использовать как рабочие шаблоны. Меньше было бы вопросов по теме и это дало бы Вам в реальную карму много плюсов))) P.S.2. Было бы классно, если бы примеры кода Вы сопроводили кратким описанием используемых средств и механизмов и пояснением, почему так, а не эдак. Добавлено через 26 минут ПыСы. Бу-га-га , прям в тему: Паттерн mvvm 0