I have been looking into MVVM recently and I seem to get the overall idea. There are a couple of niggly bits though that I do not fully understand and was hopping to get some answers here, cheers!
Is it incorrect to use one data model for the whole application. Usually if I am creating a small utility I would have all of the logical data in one class. This means i can have somethings like the following:
DataStore myData = new DataStore;
If it is OK to have one data model is it ok to have more than one model view, say one representing each window or view (This is how I envision MVVM working).
Given then above if one has multiple model views it would seem that the model would have to be declared before the first window (view), where should it be declared? should the model be passed via a reference to subsequent model views? Would this not be a source of coupling as the window or page (view) would need to know about the model to pass it to its model view since the view instantiates the model view.
Sorry if this is a lot of questions, I get the idea of MVVM in a single window or page sense but once I add multiple views my system breaks down. I can get it to work with seperate models accessing an outside source to grab its data but if the data needs to persist between views I get lost.
Thanks to all that take the time to respond!
The single most important aspect of WPF that makes MVVM a great pattern to use is the data binding infrastructure. By binding properties of a view to a ViewModel, you get loose coupling between the two and entirely remove the need for writing code in a ViewModel that directly updates a view.
The Windows Presentation Framework (WPF) takes full advantage of the Model-View-ViewModel (MVVM) pattern. Though it is possible to create WPF applications without using the MVVM pattern, a little investment in learning can make building WPF applications much simpler.
MVVM was designed to remove virtually all GUI code ("code-behind") from the view layer, by using data binding functions in WPF (Windows Presentation Foundation) to better facilitate the separation of view layer development from the rest of the pattern.
Some thoughts:
Simple applications don't necessarily require the complexity of MVVM - you may be able to get away with eliminating the ViewModel - and using the underlying model directly. Just be careful that you don't stretch this approach to the breaking point - as WPF is very reliant on things like INotifyPropertyChanged, and DependencyProperties. You don't want to start merging these into your model classes unecessarily.
Yes, it's ok. However, ... keep in mind it's simpler if there is only one Model instance - otherwise you need to deal with merging changes from multiple views when you are going to save (or losing one version's changes). If the ViewModels refer to the same underlying model this can be workable.
You cannot avoid a certain level of coupling in MVVM. However, (if I understand your question correctly) introducing coupling between ModelViews is probably a bad idea - since it is defeating the purpose of making each a discrete perspective on the model optimized for a particular view.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With