MVVM best practice for menus

user_7259063 0
Viewed 351

Long time listener, first time caller. I'm Pretty New to this and I think this is a pretty simple question.

I am building out a Xamarin.Forms application and have a number of static Menus. The question is whether it is best practice to use "OnClick" events in the "CodeBehind" for the Menu or to create a ViewModel and bind them back to navigation commands?

I have kept the code behind empty (barring binding contexts) for everything else and its annoying me that its there for the menus. Is there any benefit either way?

OnClicked: .xaml

<Button Text="Fridge and Freezer" WidthRequest="300" BackgroundColor="DeepSkyBlue" Clicked="onClickedEvent_FridgeFreezer"/>

.cs(In CodeBehind)

async void onClickedEvent_FridgeFreezer(object sender, EventArgs args)
        {
            await Navigation.PushAsync(new FridgeFreezer());
        }

OR

Binding: .xaml

<Button Text="Fridge and Freezer" WidthRequest="300" BackgroundColor="DeepSkyBlue" Command="{Binding GoToFridgeFreezer}"/>

.cs (In a ViewModel)

public ICommand GoToFridgeFreezer{ get; private set; }

async void GoToFridgeFreezer()
{
wait Navigation.PushAsync(new FridgeFreezer());
}
xamarin.forms mvvm c#
3 Answers

The whole point of MVVM is to make it so you can test as much of your app as possible without actually having to start it.

Using automated UI testing it's now possible to verify that navigation happens properly if triggered by the View, but this requires starting up the app and actually running its entire control flow. So although it's possible, it's still quite awkward and slow. There may be other frameworks that work better for this, but I've found that Xamarin.Forms Pages don't play nicely with Unit Testing at all. Using View-based navigation in my experience means that the app automatically becomes less testable.

However, if you code your navigation to happen in your ViewModels, you can test this without starting up the app. You create an instance of the ViewModel in your test, send it simulated input that's supposed to cause navigation, and observe where it tries to navigate to. This is much simpler than testing View-based navigation, and it's very fast. Most MVVM apps I've worked on (WPF, Xamarin) have had the navigation logic in the ViewModel, by that I mean an interface is injected in to take care of triggering the navigation.

Admin1

Well, the best practices advise to do everything in the ViewModel, and keep the code-behind as simple as it can be.

user_16919800

Thanks to everyone for their comments and support.

As I got into it more I found that I required Dynamism and Logic built into some of the menu options so it was a no brainer to move to a ViewModel to handle that.

If anyone else is reading this then I would suggest you go down the ViewModel route as it will, if anything give you the flexibility to change without tonnes of work.

Special thanks to user11639555, I have just started to play about with tests and that was invaluable :)!!!

Best of luck to you all :)

user_72590630
Related