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

Задача :
Нужно носимое приложение с минимальным количеством DLL в папке приложения. В этой же папке должен быть каталог с БД приложения. Интерфейс требуется сделать не-примитивным (подробнее - ниже), коим почти все обучающие примеры MVVM обладают. Данных будет не очень много (в пределах 30 МБ текста за год).

Решение :
NET Core 3 приложение на C# с использованием WPF.
БД на этапе разработки - файлы JSON, одна таблица БД - один файл. От SQLite+EF отказался на этом этапе как раз из-за того, что они тянут в папку приложения кучу библиотек. Подозреваю, это количество можно сильно уменьшить, но пока не знаю как.

Детали :
1. Набор таблиц не на 100% соответствует набору классов бизнес-модели (есть "промежуточные" таблицы для связи многие-ко-многим, а "бизнес-классов" для них, понятно, нет).
Из-за предстоящего возможного перехода на другой (или дополнительный) способ хранения данных хочу отделить бизнес-модель от модели данных. Сейчас есть:

Model\DataContext - бизнес-модель; набор интерфейсов, на которые буду ссылаться во ViewModel.
Например: IBuilding; IRoom; ISubject;

Model\Json - модель данных JSON; набор класов, которые воспроизводят структуру БД и реализуют интерфейсы бизнес-модели. Например:
JsonContext { GetBuildings(), SaveBuildings(), etc }
DbRecord { ID, IsArchive, DateModified };
Building : DbRecord, IBuilding;
Room : DbRecord, IRoom;
Subject : DbRecord, ISubject;

В перспективе вместо или в довесок к Model\Json может появиться Model\Excel, Model\SQLite, Model\Web и т.п. Таким образом, какие-то бизнес-объекты будут получать и сохранять данные не в Json, а в других хранилищах. Будет ли такое, что, например, объекты IBuilding будут загружаться частично из Json и частично из SQLite - не знаю пока. Скорее всего, нет. Т.е. источник данных для одного типа объектов только один.

Оптимально ли так реализовывать модели?

2. Где при такой реализации моделей надо держать экземпляры коллекций записей? К которым (коллекциям) биндятся элементы View.

3. Как корректно реализовать механизмы обработки изменений и сохранения записей, если требуется, чтобы только нажатием кнопки "Сохранить" можно было фиксировать изменения в хранилищах и в других окнах? Насколько я понимаю биндинг, это проблемно, т.к. например:
• Есть ListView с записями. Записи - из DataContext'ной коллекции, которая находится - где? (см. вопрос 2)
• Кликаем по записи дважды
• Открывается окно редактирования записи, DataContext'ом которого (окна) является ссылка на одну из записей коллекции.
• Вносим изменения в TextBox'ы. Учитывая биндинги, эти изменения сразу применяются к DataContext'ной записи, а значит и в общюю коллекцию записей. Т.е. нажатие тут кнопки Отмена, закрывающей окно редактирования, не приводит к игнору/отмене изменений, произошедших в этом окне.

4. Как можно подтягиваемые студией библиотеки зависимостей сложить в подпапку, а не чтобы они рядом с выходным exe лежали? VS Community 2019

_{Ваяю: MSA 2003, mdb | VB.NET + mdb/SQL Express | 1Сv8, ТК УП | C# + FDB}

И по поводу интерфейса. Вот так (схематично) предполагается его реализация.

Батюшки, сколько ж опечаток я допустил в первом сообщении... Ууу, позорище!

Об этом был как раз один из вопросов. Как это сделать с помощью VS Community 2019? Как гуглить?

EDIT: Видимо, это

Спасибо!

Остальные вопросы всё же актуальны.

Как я понял этот ответ: экземлпяр коллекции ObservableCollection<IBuilding> для MainWindow должен лежать в MainWindowViewModel. Так?
Как тогда бороться с автоматическим обновлением записей этой коллекции тогда, когда это обновление не подтверждено пользователем?
Т.е. я открываю BuildingWindow; в его DataContext ссылаюсь на IBuilding в BuildingWindowViewModel и биндю поля формы BuildingWindow на свойства IBuilding - таким образом поля формы сразу же заполняются из записи коллекции. Далее, изменяя текст в полях, я получаю одновременное изменение этой записи в коллекции, что мне НЕ нужно, т.к. в коллекции я хотел бы отражать изменения только при нажатии кнопки ОК в BuildingWindow. Надо, видимо, биндиться на копию записи коллекции? Но тут возникает вопрос про копирование ещё и всех записей IRoom, вложенных в этот IBuilding...

EDIT: Ой, по-моему, я путаю сейчас коллекцию во вью-модели с коллекцией в модели (не в БД, а в памяти)... Если так (путаю), то возникает другой вопрос - про рассинхрон этих двух коллекций. Пользователь внёс изменения в форме редактирования записи - они по биндингам попали в запись коллекции вью-модели. Далее он нажал Отмену - и теперь мы имеем запись в коллекции вью-модели, отличающуюся от записи в коллекции бизнес-модели. Или бизнес-модель не должна иметь свой экземпляр, загруженный одновременно (параллельно) с экземпляром вью-модели?
И как нам в случае отмены изменений в форме редактирования вернуть запись в ObservableCollection в исходное состояние? Только перечитать из БД/JSON, принуждая MainView обновиться?

Я прекрасно отдаю себе отчёт в этом и согласен с вами. Смысл этого "изврата" (использование JSON как хранилище на этапе разработки и на первых порах эксплуатации) - это как раз заставить себя понять, как пользовать MVVM в условиях разнородных/изменяющихся источников данных.
Мной лично уже выпущено немало приложений на разных языках и разных масштабов: моды, плагины, утилиты, носимые программы, клиент-серверные и веб-решения корпоративного/муниципального/регионального уровня, но я самоучка, пишу код редко и отстаю от мейнстримов.
Мне очень-очень хочется разобраться с этим паттерном, но академически я не умею учиться - только под реальный проект. Благо сейчас появился небольшой реальный проект с несжатыми сроками, в рамках которого я могу сделать правильно, "по науке", освоив популярный паттерн.

Eld Hasp, спасибо огромное за развёрнутый ответ!

Правильно ли я понял архитектуру решения (см.картинку)?
И мне не вполне понятно про "общую библиотеку".

Роман, как тогда правильно открывать новые окна и передавать в них объекты в качестве DataContext, а также получать обратно результат работы (Ок, Отмена, выбранный элемент списка...)? В CodeBehind окон View?

Хм... В Repo ещё должен быть "using Model", иначе Repo не будет знать о бизнес-интерфейсах из Model, которые должны быть реализованы в Data-классах Repo.

Eld Hasp, снова благодарю за полезные ссылки.

Eld HaspКириллН, в Модели не должно быть ссылки на Репозиторий.
Вы же предполагаете возможную замену Репозитория, поэтому Модель "знает" о Репозитории только его интерфейс.

Эти мои выводы сделаны на основании рассуждения - см. картинку. В нём что-то не так?

...таким образом, при смене слоя Json на слой SQLite надо будет только изменить в Model\DataContext слово Json на слово SQLite, чтобы вместо Json\JsonContext получилось SQLite\SQLiteContext. А если записывать в виде Json\Context то только namespace поменять. А вы предлагаете вариант, при котором не надо вообще ничего в Model менять? Тогда я недопонял, как это сделать. Пошёл по предоставленным ссылкам...

https://miro.com/
Сам только недавно (на онлайн-собеседовании) про него узнал. Оч понравилось. =) Особенно совместная одновременная работа.