Ok still trying to get a handle on this MVVM stuff. The View is a user control, the window will display user controls in Tabs, for a TDI interface. I have an OpenDocument method in my view model, which should of course open the document for editing. My question is how?
I assume the VM should not know about the view, or its containing window. Also, the Xaml only MVVM.. should that apply to the main window as well, which is just the shell more or less?
Thanks
Andy
Hi Andy
I think the answer to the above is a matter of preference and it can be done in many different ways... If I understand correctly, you have a list of Documents (presumably the main tab in you tab control) which when you double click (or whatever equivalent) a row in you want a new tab to be added which will allow editing of a Document object.
I use Composite WPF but the principle is the same. The setup I would have is:
The sequence of events would be something like:
Hope this is of some help.
Ok... I'm not sure I follow, but your post got me thinking.
Create an OpenDocument RoutedEvent delegate, which the main window can handle. The UserControl can listen to this event, which would be raised by the VM.
Does that sound about right?
Check out Karl Shifflets blog. He has a full app developed with MVVM that has alot of nice info/ideas on how to handle the UI.
I assume the VM should not know about the view, or its containing window. Also, the Xaml only MVVM.. should that apply to the main window as well, which is just the shell more or less?
I think that's a very valid assumption. The whole point of MVVM is that you can unit test the VM. If the VM has any knowledge of, or makes use of, any XAML types (including the View types) then you can't execute the VM in a unit test harness - thus defeating the primary point of using MVVM.
There are various technical solutions to that problem - but the basic concept is that something needs to be an abstraction layer so the VM can request that a window be displayed - but the thing it is talking to will be different at runtime and at test time.
I'm doing this right now - I have an IPresenter interface with methods like ShowView(), ShowError(), ShowStatus(), etc. At runtime my actual presenter really does render those things. At test time I have a test presenter that doesn't even try to create the view (because it can't of course), and instead just records the fact that a request was made to show a view - thus allowing my unit test to establish that the right ShowView() call was made, without actually trying to show the view.
i'm wondering then where my VM is at currently.
I had created a property, backed by a DependencyProperty, so allow a selection change in the View to automatically record the selection in the VM (its a SelectedItem property, much like the MVVMExpermiment sample).
Is this violating the seperation, since DependencyProperties come from System.Windows? Whats the alternative then?
Andy
DependencyObject and dependency properties are fine. They are used by Windows Workflow too - basically a purely non-interactive server-side technology.
My language was perhaps a little strong - but the point is that you can't use any type that won't work in a non-interactive unit test scenerio. So most XAML types (things like controls, windows, dialogs, pages, usercontrols) should be considered off limits.
Ok, thanks for that info. My mistake was thinking that System.Windows was the Wpf namespace, but I guess its more of a platform assembly.
Copyright (c) Marimer LLC