Това е много интересен въпрос.
Обикновено открих, че в приложенията на MVVM се опитвате да изолирате модел като краен резултат -- продукт/част от данни -- на View Model. Ако трябваше да имате магазин за велосипеди, например, ще видите витрината като изгледа, продавача като модела на изгледа (ако приемем, че това е велосипед с възможност за персонализиране, който е създаден по поръчка), а модела като завършен обект на велосипед.
В случай на изграждане на велосипеда, докато е в етап на "прототипиране", който трябва да бъде представен, имам склонност да го увия в ViewModel - защото има логика в него. Изглежда като допълнителна стъпка, но в крайна сметка можете да имате валидации в този ViewModel, докато го конструирате. Ако вашият модел е негъвкав за добавяне на INotifyPropertyChanged към него (или ако е генериран от услуга), ще имате проблеми, ако имате "0" гуми на велосипеда -- това трябва да създаде проблеми!
Много хора са склонни да стават малко по-мързеливи и да виждат MVVM като модел, който абстрахира прототипни модели (където въвеждането на данни се връща напред/назад, актуализира се) към модели - когато те всъщност трябва да бъдат ViewModels.
Според примера бих имал MVVM директория, която изглежда така:
Models
-Bicycle (an object that can be passed across a service, etc -- data)
Views
-BicycleCreatorView (the view or data template of the model)
-StoreFrontView (the view of the entire store/app)
ViewModels
-BicycleCreatorViewModel (the view model which CONSTRUCTS a Bicycle model as the end result)
-StoreFrontViewModel (the view model for the entire store)
Сега можете много лесно СЪЩО да накарате BicycleCreatorViewModel да има конструктор, който приема модел на велосипед и предварително попълва. Това не е необичайно. Някой може да влезе в магазин и да каже: "Хей, можеш ли да направиш това подобно на другото? Ето как изглежда." Въпреки че крайният резултат е да имаме друго свойство (вероятно просто get {}), което всъщност изобразява обект Bicycle, АКО валидирането е добро и нямаме нещо необичайно с 0 гуми, без седалка (може би това е функция?) и т.н.
И така, накратко -- винаги бих искал вашият модел (ако не можете да го разширите по НИКАКЪВ начин) да бъде обвит в негов СОБСТВЕН ViewModel за тази цел. Това би бил истинският MVVM модел. Винаги можете да използвате неща като ReactiveUI или други инструменти, които могат да обгръщат свойствата. Може да отделите малко повече време за това, но крайният продукт ще бъде много по-гъвкав и по-малко податлив на грешки от друг. По същество вие вече правите това, но вероятно бихте могли да го пренапишете, така че да изглежда "по-чисто" и да има начертана линия.
На теория можете също да проверите дали можете да подходите към него по метод като този:
Има ли аспектно ориентиран инструментариум, който бихте могли да използвате потенциално? Може би да направите вашите класове частични, за да включите INotifyPropertyChanged в разширението и след това XmlIgnore определени части, ако сериализацията е проблем/въпрос?
Проблемът е, че имаме много малко познания за това откъде идва моделът и как го използвате. Надявам се това да ви помогне или да ви даде интересна идея. Ще се радвам да видя дали предлагате решение, което е по-„вдъхновено“ от стандартното.
person
Locke
schedule
13.08.2014
ParentClass
са рендируеми данни за използване извън моето приложение. В контекста на моето приложение това все още са само данни за модела. - person William Thomas Waller   schedule 13.08.2014