в полной мере.
Спасибо за краткое введение в курс дела, я примерно так и понял. Но я хотел бы какие-нибудь признаки в каждом "столпе" выделить. Если я правильно понял, то
-View (вместе с code behind) содержит обработчики обновления свойств контролов, его ViewModel и подписывается на его событие-уведомлялку
-VM: тут вся логика содержится. Запросы к БД, оперирование объектами предметной, вычисление значений (и запись их в свои свойства) для обновления GUI
-Models. А тут чисто описание структур данных, которыми оперируем во VM
Признаки верны? Ну да, я понимаю, что могут быть отклонения, нет "единственно верной" схемы. Но тем не менее
upd. Что-то с моделью в этой схеме не так. Ей же не о чем уведомлять VM об изменениях, да?
Верно, подпроекта нет. По MVVM там целиковый солюшен. Логика в x.Services, вьюмодели в x.Presentation, представление в x.Presentation.%FrameworkName%
>VM: тут вся логика содержится Нет, в VM содержится только логика представления. Иначе говоря, логика взаимодействия домена с пользователем. Походы в БД и прочее обычно вынесено в отдельные объекты >Models: А тут чисто описание структур данных Вполне возможно, что такая структура файлов и папочек имеет место быть, но это не имеет никакого отношения к Model в терминологии MVVM.
Обсуждают сегодня