I know there is many ways to Navigate to other page from ViewModel.
I'm not sure is this a good idea or not, since MVVM's purpose is to separate View from ViewModel, but Navigate to other page within ViewModel mean there's a couple between View and ViewModel, that being said, if I change View name, I need to change URI (string) in ViewModel too.
I want to know, is it right to call Navigate to other page from ViewModel? If it's wrong, what's the correct (or better) way to navigate to other page?
It's both right and natural.
When you make a navigation request, the "name" you provide as part of the Uri is the name with which your View class has been registered in the container. Since registering classes with the container is done by the module itself and not the View or the ViewModel, you are not introducing coupling between the View and ViewModel.
That said, if you want to customize the way that Prism interprets your navigation requests, you can always write a class implementing IRegionNavigationContentLoader. If you register this into the container, Prism will resolve your own class instead of the built-in RegionNavigationContentLoader. But it's not the simplest thing in the world to do.
Why don't you create a separate class that will keep the logic for navigation? In that case you'll only need to send a message from ViewModel that program should change the View and details would be decided arbitrally. With that approach you still have no direct connection between View and VM
Related
My project using MVVM design pattern using Prism and Unity, basically following the famous Prism video by Brian Lagunas, but the video didn't mention how to create/use partial view, User Control used in other User Controls.
I'm trying to create custom partial view(UserControl) can be reused in other page (User Control). For example, a View contains a "Browse" button Binding SelectFileCommand and Publish the file Path when done. If I have two of this View in one page, how can I subscribe to the correct command? Both Commands called same name.
For using Partial View:
Register View Type in Module like this:
container.RegisterType<IPartialView, PartialView>();
and use the view directly in page like this:
<views:PartialView DataContext="{Binding PartialViewModel}" />
I'm not sure if this is the correct way to implement Prism MVVM pattern. Please let me know if this is the wrong idea, and how to implement these kind of Partial View.
Thanks a lot.
I'm not sure I understand what you need but I'll give it a try.
If your partial view is in another module, first, you can't use elsewhere than in this same module. You could use some IPartialView, but I'm not sure this is needed here, Prism gives much simpler solutions.
The simplest way to do what I think you want to do would be to have a region where you want to have your partial view. You would use RegisterViewWithRegion in the module definition to register the PartialView against the corresponding region(s).
That way, if you have this partial view several times, you will have several regions with the same name, and only one registration of PartialView in the module. Just give the right DataContext to each region.
I am looking for a truly decoupled way of supporting navigation in a Silverlight application using MVVM. I am trying to accomplish more of a "purist" implementation of the pattern where the UI is completely separated from the ViewModels so that the application can actually run entirely without a UI. To do this, I need to support navigation without UI concerns.
I have several ideas how to accomplish this (with Messaging, etc) but haven't come up with a good way of "mapping" the View to the ViewModel so that the UI can show the appropriate View when the ViewModel is "displayed". I recall coming across an article some time ago that described a solution to this very problem but can't seem to locate it online anymore.
Does anyone know how to find this article or have any experience solving this problem?
So here's my somewhat long-winded description what we ended up doing:
First, we decided to use the built-in Page Navigation framework. We had multiple reasons but since it is built-in and is also the navigation framework du jour in Windows 8, we opted to try this approach.
I should also mention that we use MVVM Light and MEF in our applications. (This comes into play below.)
To make this work, we created an application Shell (UserControl) that contains the Frame control. The Shell's DataContext is set to an instance of the ShellViewModel which exposes a single CurrentPage property (of type String). We then bind the Frame's Source property to CurrentPage. This approach is similar to Rachel's app-level ViewModel.
The ShellViewModel registers with the Messenger to receive CurrentPageChanged messages. When the message is received, the CurrentPage property is updated, the PropertyChanged event raised and the UI updated. The message originates from the NavigationService (which implements INavigationService and is injected/imported using MEF).
The NavigationService exposes a NavigateTo method which accepts the string name of the ViewModel representing the destination. This name matches the contract name applied to the ViewModel when exported (using MEF) and used to lookup the instance using our ViewModelLocator.
In the NavigateTo method, we use the ViewModelLocator to retrieve the ViewModel instance, call Deactivate on the current ViewModel (if one), call Activate on the new ViewModel then send the CurrentPageChanged message with the name of the new view as a parameter. Activate/Deactivate are helper methods on the ViewModels that allow us to perform any necessary tasks when the ViewModel is navigated to or from.
This appears to be working well and gives us a very MVVM-ish implementation with all navigation isolated from our ViewModels via the INavigationService and messaging.
The only down-side right now is that while we are using string constants in code to represent the ViewModel names, we are still hard-coding the strings in the Views to set the DataContext. I will be looking into a way to set the DataContext automatically as part of the navigation 'tooling'.
I should mention that this approach was parsed together from a number of sources, including (but not limited to) Rachel and the following links:
http://blogs.microsoft.co.il/blogs/eladkatz/archive/2011/01/25/adapting-silverlight-navigation-to-mvvm.aspx
http://blog.galasoft.ch/archive/2011/01/06/navigation-in-a-wp7-application-with-mvvm-light.aspx
http://www.geoffhudik.com/tech/2010/10/10/another-wp7-navigation-approach-with-mvvm.html
Usually I have a ViewModel for the entire app, and it contains the CurrentPage and all navigation event handling.
On the View side, I use a ContentControl with it's Content bound to CurrentPage, and use a DataTemplateSelector to determine which View to display for which ViewModel
There's an example here if you're interested, although it uses DataTemplates instead of a DataTemplateSelector.
I need an elegant solution (I am working on silverlight 4.0) to solve this simple problem(?) using the MVVM pattern:
My mainpage xaml has my two custom user controls like this (say):
<uc:MyCustomUC1>
<uc:MyCustomUC2>
Each one has its own view model and both these user controls are independent of each other.
When an asynchronous operation in MyCustomUC1 has completed, I want an ICommand in MyCustomUC2's viewmodel to be invoked thus refreshing data in MyCustomUC2. I want this done by the parent page and all in xaml.
Exposing dependency properties, event handlers etc in the user controls...anything is ok since I own the user control ...whatever makes sense.
Any ideas ?
Use Mvvm Lights messenger, you can register a listener in MyCustomUC2's viewmodel to refresh. Then in MyCustomUC1's async call back, send the message to refresh.
You could use a PropertyObserver, which I believe you can find info on here:
Property Observer.
It'll allow you to check when something has changed in one ViewModel and then take the appropriate action in another. I've used this quite a bit recently in a project and it has worked pretty well.
Apologies if I've picked up the question incorrectly.
This seems to be a really naive question, but how on earth does one get the NavigationService from outside of a page, like say perhaps a view model? Everybody says that navigation should occur at the view, but I keep thinking, this is not a web page, its an application. The view model and business logic should control application flow, not the view. Is this in fact naive?
As far as I understand it, operations involving the View, i.e. UI, should be done by the View exclusively. When working with MVVM, the UI should not be controlled by the ViewModel or BusinessLogic directly (since they are not supposed to know anything about the concrete implementation of the View) but work with Messages.
That means, if we want to open an Editor window from the ViewModel we send a Message from the ViewModel that we want to open it and receive it in the View and open the window there. The same is valid for Navigating through different pages, where you would receive the Message in the MainPage (or whatever holds you pages that you want to navigate through) and handle everything there.
An alternative to that would be using a DialogService or something like that, which handles opening windows in a central place. However, since the NavigationService is a property of the Page class, we need to handle the message in the Page.
Example code, using the MVVM Light Toolkit: (not tested, partly taken from Shawn Wildermuth's RiaXBoxGames example):
ViewModel (e.g., put that in a Command for a Button):
Messenger.Default.Send<bool>(true, "GoToNextPage");
View (e.g. put that in a Constructor):
Messenger.Default.Register<bool>(this, "GoToNextPage", ignore =>
{
// your code to go to next page
});
another option is to create an event on ViewModel, fire this event when Command occurs and subscribe View to this event. Inside EventArgs you can carry which page to navigate to etc. I think simple and testable solution.
Robert
I just pass a reference to the Frame when I create the View-Model.
I am implementing MVP/M-V-VM in WPF and I'm having good luck with it so far. However, I don't see how this model supports implementing Modal dialog boxes. I've derived my work from Crack.NET (http://www.codeplex.com/cracknetproject) to learn how this stuff works.
I have a ShellView view (which is just XAML) that has a menu on it. The menu binds to a command in the ShellModelView that says "EditPreferences".
The ShellModelView implements the ICommand for EditPreferences and here we want to put up a dialog box to let the user edit preferences for the application.
Several problems here:
1. The ShellModelView doesn't have a reference to the ShellView to properly parent the dialog. The ShellModelView is the DataContext of the ShellView but I don't see a backreference that's setup.
2. The ShellModelView shouldn't be loading explicit UI anyway. So what's the proper interaction model here?
3. How do I build up my PreferencesDialog so that it's properly separated between logic and view as well? PreferencesDialog itself needs to be a Window so you can call ShowDialog on it, but that means you need a reference to the Window (e.g. View) in order to instantiate it. Ideally I should be able to unit test the code/validation within PreferencesDialog without instantiating the view (using a Mock view perhaps?).
Perhaps this is not the appropriate way to look at it, but this is the approach I take with M-V-VM in WPF. Opening windows and dialog boxes or an "EditPreferences" view are UI specific functions. If I were to rewrite the your entire UI replacing all of the views, I may wind up combining the "EditPreferences" view with another view, and therefore never want to open it in another screen. If this were tied to the ViewModel, it would be difficult to get around. In this particular situation, I would have a button or menu item in my "ShellView" that creates a new instance of my "EditPreferences" view, and then passes in the "EditPreferences" ViewModel which may either come from a property in my "ShellViewModel", or perhaps my "EditPreferences" view instantiates the ViewModel itself.
Here is a similar question on SO that basically says the same thing: M-V-VM Design Question. Calling View from ViewModel
You will need a controller in your case. The controller should be in charge for showing the preference dialog window.
As I can envision it the controller should be responsible for creating the ShellModelView and binding view's DataContext to it. The controller should be also responsible for handling command execution of EditPreferences. In the execution logic the controller will create a new PreferencesDialog and its corresponding view model.
You can find similar patterns in Prism if you haven't already did it. You can also reuse the DelegateCommand provided there :)
Have the PreferencesDialog implement a interface that is one of the properties of the EditPreference command. The command would interact with the dialog through the interface. For Unit Testing the mock object would implement the interface instead.
The dialog class then can reside on your highest layer.
My 2 cents is:
Pass some kind of viewfactory contract as the command parameter or inject a viewfactory contract into the view model. The view model will them use the viewfactory to create any modal/non modal views it needs. The viewfactory could also take in as a parameter of its Show/ShowModal method a viewmodel to display. Furthermore, the viewfactory could use a datatemplate to display any viewmodal passed in as a parameter.
Add a ShowViewModel property to the viewmodel in question. A DataTrigger could then watch for this property and when it is of a particular type show the view, etc.