I see in many posts that communications between viewmodels should be done using a messenger bus.
What I wonder is, is it considered bad to simply execute a child vm method from the main vm?
Suppose having a view with a TabControl, where each TabItem is a child viewmodel.
When I close my application, I need to store my settings calling a SaveSettings() child vm method.
I need to know if it's a bad code, and in case why.
main view
-> closingEvent
-> call MainVM SaveAllSettings()
-> for (ChildVM childVM in allTabs)
--> childVM.SaveSettings() (public method)
If your objects are already coupled to each other, i.e. if a parent view model already has a strong reference a child view model, there is no need to use a messenger or an event aggregator to communicate between them. Then you can (or rather should) call any methods of the child directly.
There are certainly cases where these kind of parent/child relationsships exist and it's not necessarily a bad thing or a sign of poor design. It all depends on the relationsships of your objects really.
Related
I've created a dialog service using interfaces to show custom dialog/confirmation boxes (I know that Prism comes with this ability but the dialog boxes don't appear to be customizable and don't match my layout/color scheme). The dialog service has a register function that registers the dialog view type with dialog viewmodel type in a dictionary. This is done so that a viewmodel can be passed in and in a loosely coupled fashion, an instance of the needed view can be created. The code looks like this:
private readonly IDialogService dialogService = new DialogService(Application.Current.MainWindow);
// Registers the confirmation window viewmodel with the confirmation window view
dialogService.Register<ConfirmationWindowViewModel, ConfirmationWindow>();
so my initial thought was to try to create this in the unity bootstrapper (because of the registration passing in views and viewmodels) but I can't seem to find a way to do that and pass in the dialog service.
I must note that the constructor for the main window viewmodel also injects the region manager and the event aggregator for Prism; I had tried creating an instance in the bootstrapper and registering the instance but the creation of the region manager vs the injection causes errors. If I declare and initialize the dialog service in the main window viewmodel it of course works but from my understanding of MVVM we don't want the viewmodels to have any knowledge of the views so I'm trying to find another way to do it, without breaking IoC for region manager and event aggregator.
I am new to MVVM and Prism/Unity so my grasp of these concepts isn't fully solidified yet.
I know that Prism comes with this ability but the dialog boxes don't appear to be customizable and don't match my layout/color scheme
You can create whatever you like as dialog, just derive from PopupWindowAction and override CreateWindow (and other methods as needed) to create the dialog you always wanted.
In case anyone sees this later and is curious, my end decision was to get rid of the 'Register' function altogether in favor of a solid convention instead.
Previously, I would use this function and kept a dictionary of all the registered views/viewmodels:
dialogService.Register<ConfirmationWindowViewModel, ConfirmationWindow>();
this would register take the and store them in the dictionary so I could later pass in a viewmodel and create an instance of the appropriate confirmation message view. Instead I removed all code regarding this part of the solution and replaced it with some reflection mixed in with naming conventions.
Step 1: Ensure all views are named with the suffix View at the end.
Step 2: Ensure all viewmodels are named with the suffix ViewModel at the end.
Step 3: Ensure these are all in appropriately named namespaces (views in views namespace and viewmodels in viewmodels namespace).
(most of this ^^ is done anyway)
Final Step: Replaced dictionary with this code:
var viewTypeName = viewModel.GetType().AssemblyQualifiedName.Replace("Model", "");
var viewType = Type.GetType(viewTypeName);
in the dialog interface. Now, no matter what viewmodel is passed in, it will pull the appropriate view with less code and no necessary linking as was done before.
I am trying to program in MVVM and I have the following use case:
A TextBox's text is bound to a property in the VM
A Button is command bound to a relay command
When the user presses the Button, the web browser's Navigate(url) method is called with the URL being the text in the TextBox
Above is the use case I want to create, but 1 and 2 is possible using the MVVM design pattern, but I could not find an adequate way to invoke the browser's Navigate() method. First of all, is it possible to call a method of a control from VM (please let me know if there is a way)? And in the above use case, what would be the appropriate way to structure the program if it is not possible?
Thanks
You could do the following:
Add a property MyUrl to your ViewModel
Bind MyUrl to your WebBrower's Source property
Make sure the property implements INotifyPropertyChanged. Then your Xaml:
<WebBrowser Source="{Binding MyUrl}" />
What if you REALLY wanted to call a UI method from the ViewModel?
If you ever do run into a situation where you absolutely need to call a method on a UI control for instance, you can hook up events on the ViewModel and then your UI registers to this event and does something UI specific...
VM code...
//... some VM logic
EpicNavigateEvent(url) // raise event, allowing UI to handle how
In your code-behind on your view (this is the part where some MVVM purests freak), you could register the event:
myVm.Navigate += doSomeNavigation;
...
public void doSomeNavigation(string url)
{
// call Navigate
}
I've successfully used this approach for applications where we have a single ViewModel layer and multiple technologies hooked up the views (WinForms, WPF and Asp.Net).
If you're looking for something more elegant, have a look at the User Interaction Patterns on MSDN.
The concept is the same though: Call something on the VM and the View is handles it appropriately.
Common scenarios for this type of approach is want to show a message to the user from the VM. Your VM should raise an event saying: ShowMyMessage("You're awesome"), then your UI is notified and handles it: MessageBox.Show(msg) or whatever.
As long as you stick to there rules you should be golden:
ViewModels should NOT be concerned about UI code
Views must ONLY handle the presentation of the data provided by your ViewModels.
Don't overcomplicate it. KISS...
I am doing some data presentation using CM and WPF, and some of the data tabs have very similar formats but have to be kept in separate VM containing tabs as part of the standard for the application.
My initial thoughts were that I could do this programmatically in the VM by looking for any property pertaining to Views on the VM object (which itself is a Screen object derivation.) Its direct superclass is used as a contract for [ImportMany] so that the parent VM and View can tabulate the collection.
[ImportingConstructor]
public PartiesMasterPartiesViewModel(
IEventAggregator events,
IHelpService help,
ResourceManager<B_Action> actionResource,
IActionService actionService)
: base( events, help, actionResource, actionService)
{
}
protected override void OnActivate()
{
base.OnActivate();
this.Views.Add(new KeyValuePair<object, object>(this,
new PartiesMasterListView()));
}
So either I am not using this property correctly, or it does not do what I thought it does and I need to use another way.
Another way I'm thinking of doing it this explicitly instantiating multiple instances of the same viewmodel and manually adding them to the collection, but this seems like it would be violating what MEF's [ImportMany] would be here to do and weaken the design of the application.
The simplest way to achieve a view shared by multiple view models is to configure the ViewLocator with some extra rules.
In this example I have two view models Examples.ViewModels.SharedData1ViewModel and Examples.ViewModels.SharedData1ViewModel and a single view Examples.Views.SharedDataView that I'd like to be the view that Caliburn.Micro locates for both by default.
In my set up code I can add the following simple regular expression to the ViewLocator.
ViewLocator.NameTransformer.AddRule(
#"^Examples.ViewModels\.SharedData(\d+)ViewModel",
#"Examples.Views.SharedDataView");
Let's consider a simple application that consists of two views and two view models.
There is a button on FirstView which fires ShowViewModel and a button on SecondView which fires ShowViewModel.
Let's say that FirstViewModel also subscribes to messages of type MyMessage in the ctor.
Scenario: the user starts application, presses button on FirstView and than on SecondView. Now we have the following back stack: FirstView->SecondView->FirstView. Since ShowViewModel always creates a new instance we actually have TWO FirstViewModel objects in memory. Each of them is subscribed to MyMessages!
What can I do to avoid this? I want to make sure that only one instance of each ViewModel class is subscribed at the same time. Do I have to use platform dependent handlers in Views (like OnNavigatedTo/OnNavigatedFrom) to avoid this? Or is there a cross platform way?
I have more of an architectural question. I'm trying to implement MVP in C# as follows:
IView creates Presenter
IPresenter has a property IView which holds View, that is bound to it
View CAN be Form, but Presenter does not distinguish between Form and non-Form types, so View can be swapped and the solution is to be testable
What I sometimes need to do, is to open some other form. E.g., I have Browser view with DataGrid and when I double-click on a grid item or select something and click Edit button, Edit event is raised and Presenter acts.
Now, Presenter needs to open a Editor view, which is also a Form, but the problem is, presenter should not construct the Form itself, because then it is impossible to Mock the View.
I'm pretty struggling with the proper concept. My code looks something like this:
var editorView = new EditorForm();
editorView.Presenter.Entity = SelectedEntity;
editorView.ShowDialog(View as Form);
Under the hood, EditorForm constructor constructs the presenter and assigns this (View instance) to the presenter:
public EditorForm()
{
Presenter = new EditorPresenter(this);
InitializeComponents();
}
From the View perspective, I can swap it to MockView simply by implementing the Mock and then instantiating the same Presenter from MockView's constructor.
I was searching for some other Q&A here and over the web but did not find anything suitable.
Thank you for all your hints.
If I understand your conception,
I suggest you to project the Edit presentation issue according to MVP pattern as you did with main view.
So create IEditView and EditPresenter and finally in main presenter create instance of EditPresenter. Generally control the edit view through its presenter.
After some brainstorming with some friends, we came to the conclusion, the best way to handle the case of instantiating different set of Views for production (FormViews) and different set for testing (MockViews) is constructing them in some context - in my case, Spring context is an option.
So far, I consider this as an answer for the problem. If you have some more clever solution, please feel free to share!