views:

304

answers:

3

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!

  1. 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;
    
  2. 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).

  3. 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!

+4  A: 

Some thoughts:

  1. 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.

  2. 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.

  3. 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.

LBushkin
Absolutely agree: one of the benefits of the data binding architecture is that you can work in a simplified model-view architecture and scale up to the more complex MVVM approach only when your views start demanding it. And I wouldn't shy away from implementing INotifyPropertyChanged on your model classes in order to support that simpler architecture (though I agree once you start needing to wheel out DPs you're probably into view model territory).
itowlson
Yep you understood correctly. I understand that I could get away with shortening the process but I am trying to (frustratingly I may add) learn MVVM before I take on bigger apps. It seems my overall problem is persisting data between models. Maybe I have the concept of a model wrong, I will edit my post to reflect this.
DeanMc
You should avoid having MV's responsible for managing persistent data. They should immediately (or at clearly defined points) merge their changes into the underlying model classes. This avoids having to deal with persistence differencing between different views.
LBushkin
+1  A: 

My own Experience:

  1. I do not see anything wrong with using one data model for your entire application, depending on what you are wanting to do. As long as you keep it separate from your View you are staying within the MVVM design pattern.

  2. I personally like using a ModelView for each one of my Views. I think there are different arguments on it, but I personally think everything stays more modular and unit testable by doing this.

  3. I try to avoid coupling between ModelViews. If i have a ModelView for each of my Views I declare each ModelView separately in each one of the Views. I then instantiate each View into my Main View through events. This stays with the MVVM pattern, and you can Unit Test each one of your ModelViews separately.

I wouldn't be surprised if you have already read this article, but for those out there wanting to learn about the MVVM design here's a good Link.

jsmith
Holy cow that is a dense article, I wont pretend to understand everything in it but at least it gives me a to do list of things to learn! Thanks!
DeanMc
+1  A: 

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; `

This is fine. Your data model is your data model and should represent the data in the best way possible, be it in one class or 1000.

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).

Absolutely, in my opinion that's exactly what you should do. In general I would say you want one view model per view, whether a view is a control or a window. There may be cases where you find that having more than one view model for a particular view would be helpful, but I would look first to make sure I didn't have a view that should be split up.

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.

Now you're entering religious territory. I'm going to punt on this a little and say do what makes sense for your application. That said, if you want to reduce the coupling between your model and your views / view models, I would highly recommend extracting an interface from your model class(es). It would be fairly simple to create your model in your App.xaml.cs file and then pass it to the view (model) as an implementation of an interface.

Jon Norton
@ your last point: I thought that as it seems to be the least answered part of MVVM Most examples show single usage examples but I have yet to see a concrete example of persistence through models. Thanks I will tinker with your suggestions!
DeanMc