1

An example is switching the main view according to the selected item in a hamburger menu. Also sometimes it is just a small part of the GUI that changes according to the application state or according to user interaction with other parts of the GUI.

In WebForms days we used to create a tab control and hide the tab buttons bars and change the current tab page programmatically. Or stack the views on top of each other in design and in runtime hide all but one.

In WPF and MVVM I've seen people creating DataTemplate for each view, attach each to a view model and switch by changing the bound object to be of a different view model type and so the view changes.

I can see why that is a good idea for the hamburger menu views, but for some other cases, there are not necessarily a view model for each view. And in that case I'd like to escape having to create dummy view models for each view just to be able to switch between them rather than really having different types of data that I need to bind to each view.

Am I right to be concerned about this design detail?

Anyone had the same situation? What was the way you achieved the switch view effect?

In general, assuming there is no different type of data attached to each of the views to switch between, is it a correct practice to create view models just for something that is purely GUI? In other words, is view models more coupled to the data and what kind of data is available or to the GUI and the types of view we need to cover? And should we write the code for changing views on certain triggers in code behind in case we agreed that this is purely GUI and view models are not to be involved?

  • If any data binding at all takes place in your View, it will almost certainly have a companion ViewModel. – Robert Harvey Nov 9 '17 at 4:06
  • 2
    For detailed guidance on navigation techniques in WPF, have a look here: prismlibrary.readthedocs.io/en/latest/WPF/08-Navigation – Robert Harvey Nov 9 '17 at 4:11
  • 1
    I have done lots of MVVM, although not with WPF. Views don’t have to be bound to a view model, you can have a view for example that just shows your application logo. When I have an area that can display different data at different times I create a view for the outer container and have it subscribe to an event that causes it to replace the view that it contains. There must be a way to do this in WPF. BTW are you using Prism? – bikeman868 Nov 9 '17 at 5:59
  • @bikman868 I've added prism as a dependency in my project but I am totally new to using it. So regardless of the framework, in your solutions, when your view get the event to change how it looks, do you change that using code behind? i.e. it is not a punch of booleans to hide and show coming from view models right? – Bishoy Nov 9 '17 at 6:09
  • @RobertHarvey, I am currently reading that, thanks for sending the link. As said I am new to using Prism – Bishoy Nov 9 '17 at 6:10
1

In MVVM, the ViewModel contains the state of your UI. The View is merely a reflection of that state. This reflection of state is accomplished via databinding, converters, styles, etc.

I think what you want is a state variable on your ViewModel and have visibility of various UI bits bound to that state.

First, define a state enum and create a property on your VM:

enum ViewState
{
    State1,
    State2
}

class MyVM
{
    public ViewState ViewState {get;set;}
}

Then in your view, you can hide/show UI elements using triggers:

<StackPanel>
    <StackPanel.Style>
        <Style TargetType="StackPanel">
            <Setter Property="Visibility" Value="Collapsed" />
            <Style.Triggers>
                <DataTrigger Binding="{Binding Path=ViewState}" Value="{x:Static local:ViewState.State1}">
                    <Setter Property="Visibility" Value="Visible" />
                </DataTrigger>
            </Style.Triggers>
        </Style>
    </StackPanel.Style>
</StackPanel>
1

is it a correct practice to create view models just for something that is purely GUI?

Yes, it is correct, since the core purpose of having a ViewModel is to represent something in your UI. Plus, you can unit test these changes in the UI by testing changes in your view models.

should we write the code for changing views on certain triggers in code behind in case we agreed that this is purely GUI and view models are not to be involved?

If these are only pure GUI concerns, you could either write this trigger in code-behind, in XAML or make use of VisualStateManager. I think all of these options address your concern. But, you won't be able to unit test your GUI flow with these options IMO.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.