Another major gripe for me & my team was redundancy. We found ourselves, time and time again replicating Properties on ViewModel & Model!
[EDIT: This could have been because what we did was more of a PresentationModel. What we did in essence was to isolate Models so thoroughly as to make them passive. Even INotifyPropertyChanged were raised to ViewModel and ViewModel propagated the changes back to the screen.
Blogging about the subtleties of MvvM vs. PresentationModel doesn’t seem to be on anyone’s priority. :) So, let’s just say, the amount of code you write in the above model is “just too much!”]
While, we did agree that ViewModel would primarily have items pertaining to UI and we did understand a single ViewModel can actually encapsulate/unify multiple models, what we had most of the time was a single ViewModel linked to a single Model.
The dynamic nature of XAML where strings are converted using Value/Type converters and C# 4.0’s DynamicObject seemed a great fit! Before jumping to DMvvM, I’d like to start from how I approached the design statically, with MvvM, the types of issues I ran into and then how the same can be alleviated when using DMvvM.
Post a Comment