MVVM & Advantage

MVVM is a pattern that is used while dealing with views created primarily using WPF technology. Therefore, it would help a great deal if you have prior exposure to WPF and its bindings.

Xamarin.Forms is designed with MVVM in mind, and you don’t need a framework to develop a Xamarin.Forms application, with the MVVM pattern. As your application becomes, MVVM Frameworks do contain a lot of things to help you, and are certainly worth a look.

The well-ordered and perhaps the most reusable way to organize your code is to use the 'MVVM' pattern. The Model, View, ViewModel (MVVM pattern) is all about guiding you in how to organize and structure your code to write maintainable, testable and extensible applications.

Model − It simply holds the data and has nothing to do with any of the business logic.
ViewModel − It acts as the link/connection between the Model and View and makes stuff look pretty.
View − It simply holds the formatted data and essentially delegates everything to the Model.

  

Separated Presentation

To avoid the problems caused by putting application logic in code-behind or XAML, it's best to use a technique known as separated presentation. We're trying to avoid this, where we will have XAML and code-behind with the minimum required for working with user interface objects directly. User interface classes also contain code for complex interaction behaviors, application logic, and everything else as shown in the following figure on the left side.

• With separated presentation, the user interface class is much simpler. It has the XAML of course, but the code behind does as little as is practical.
• The application logic belongs in a separate class, which is often referred to as the model.
• However, this is not the whole story. If you stop here, you're likely to repeat a very common mistake that will lead you down the path of data binding insanity.
• A lot of developers attempt to use data binding to connect elements in the XAML directly to properties in the model.
• Now sometimes this can be okay, but often it's not. The problem is the model is entirely concerned with matters of what the application does, and not with how the user interacts with the application.
• The way in which you present data is often somewhat different from how it's structured internally.
• Moreover, most user interfaces have some state that does not belong in the application model.
• For example, if your user interface uses a drag and drop, something needs to keep track of things like where the item being dragged is right now, how its appearance should change as it moves over possible drop targets, and how those drop targets might also change as the item is dragged over them.
• This sort of state can get surprisingly complex, and needs to be thoroughly tested.
• In practice, you normally want some other class sitting between the user interface and the model. This has two important roles.
  
  • First, it adapts your application model for a particular user interface view.
  • Second, it's where any nontrivial interaction logic lives, and by that, I mean code required to get your user interface to behave in the way you want.
    

What Xamarin.Forms Includes

In relation to MVVM, Xamarin.Forms includes the following two features.

• Binding Engine
• IoC container

Perfect use for small apps, View, ViewModel and not much else. The IoC container is fast but lacks the ability for dependency injection. With this simple setup you can do.

• View = Any UI and UI related logic
• ViewModel = Visual State and Navigation
• Model = Business Logic and Data

The View and ViewModel are easily bound by doing

this.BindingContext = new MyViewModel();

And in your ViewModel, you can easily do

DependencyService.Get<MyModel>();

To gain access to your model. And it works as expected and is rather lean. For very simple, demo or small apps, this will be a viable option.

Xamarin.Forms MVVM Frameworks Include

When your application gets bigger, or has a larger team, it becomes harder to manage, and due to a lack of separation of concerns, can cause headaches maintaining and upgrading it. The following are the advantages of including an MVVM framework.

Navigation

Most MVVM frameworks include very advanced navigation. Instead of doing this:

await _navigationPage.PushAsync(new Page());

You would do something similar to this.

// MVVMCross
await _navigationService.Navigate<MyViewModel>();

// Exrin
await _navigationService.Navigate("pageKey");

On top of this, they include more advanced navigational features such as SilentPop, NoHistory and Page caching just for starters. Navigation is the most highly rated reason to use an MVVM framework.

Dependency Injection

Some include a Dependency Injection framework, others get you plug it in.

Xamarin.Forms only includes resolving the dependency via

DependencyService.Get<Type>();

Other frameworks allow constructor injection which allows you to do this.

public class MyViewModel(INavigationService navigationService)

This is the preferred approach, allowing you to inject dependencies, and have them clearly visible, rather than hidden inside the ViewModel or Model.

Extendable Binding

MVVMCross has some further binding enhancements. Instead of

Text="{Binding SomeValue}"

You could use

Text="{mvx:MvxBind SomeValue, FallbackValue='Nothing'}"

However MVVMCross at this point doesn’t have the Source property. But you can easily interchange them. Xamarin.Forms binding however, is normally suitable for all situations.

Enhanced Commands

Xamarin.Forms includes a default Command. Commands are what are bound to the Command properties of Elements such as Buttons or things that have a user action associated with them, and executing them via your ViewModel. This includes things such as preventing double clicks automatically, and background threading.
Some additional things are automatically setting an IsBusy flag, or implementing INotifyPropertyChanged, which can also be used with other properties to signify any changes.


Advantage 

MVVM pattern is ultimately the modern structure of the MVC pattern, so the main goal is still the same to provide a clear separation between domain logic and presentation layer. Here are some of the advantages and disadvantages of MVVM pattern.
The key benefit is allowing true separation between the View and Model beyond achieving separation and the efficiency that you gain from having that. What that means in real terms is that when your model needs to change, it can be changed easily without the view needing to and vice-versa.
There are three important key things that flow out of applying MVVM which are as follows.

Maintainability

• A clean separation of different kinds of code should make it easier to go into one or several of those more granular and focused parts and make changes without worrying.
• That means you can remain agile and keep moving out to new releases quickly.

Testability

• With MVVM each piece of code is more granular and if it is implemented right your external and internal dependences are in separate pieces of code from the parts with the core logic that you would like to test.
• That makes it a lot easier to write unit tests against a core logic.
• Make sure it works right when written and keeps working even when things change in maintenance.

Extensibility

• It sometimes overlaps with maintainability, because of the clean separation boundaries and more granular pieces of code.
• You have a better chance of making any of those parts more reusable.
• It has also the ability to replace or add new pieces of code that do similar things into the right places in the architecture.

The obvious purpose of MVVM pattern is abstraction of the View which reduces the amount of business logic in code-behind. However, following are some other solid advantages −

• The ViewModel is easier to unit test than code-behind or event-driven code.
• You can test it without awkward UI automation and interaction.
• The presentation layer and the logic is loosely coupled.

Disadvantages

• Some people think that for simple UIs, MVVM can be overkill.
• Similarly in bigger cases, it can be hard to design the ViewModel.
• Debugging would be bit difficult when we have complex data bindings.

MVVM pattern consists of three parts − Model, View, and ViewModel. Most of the developers at the start are little confused as to what a Model, View and ViewModel should or shouldn't contain and what are the responsibilities of each part.

In this chapter we will learn the responsibilities of each part of the MVVM pattern so that you can clearly understand what kind of code goes where. MVVM is really a layered architecture for the client side as shown in the following figure.

• The presentation layer is composed of the views.
• The logical layer are the view models.
• The presentation layer is the combination of the model objects.
• The client services that produce and persist them either directed access in a two-tier application or via service calls in and then to your application.
• The client services are not officially part of the MVVM pattern but it is often used with MVVM to achieve further separations and avoid duplicate code.

Model Responsibilities

In general, model is the simplest one to understand. It is the client side data model that supports the views in the application.

• It is composed of objects with properties and some variables to contain data in memory.
• Some of those properties may reference other model objects and create the object graph which as a whole is the model objects.
• Model objects should raise property change notifications which in WPF means data binding.
• The last responsibility is validation which is optional, but you can embed the validation information on the model objects by using the WPF data binding validation features via interfaces like INotifyDataErrorInfo/IDataErrorInfo

View Responsibilities

The main purpose and responsibilities of views is to define the structure of what the user sees on the screen. The structure can contain static and dynamic parts.

• Static parts are the XAML hierarchy that defines the controls and layout of controls that a view is composed of.
• Dynamic part is like animations or state changes that are defined as part of the View.
• The primary goal of MVVM is that there should be no code behind in the view.
• It’s impossible that there is no code behind in view. In view you at least need the constructor and a call to initialize component.
• The idea is that the event handling, action and data manipulation logic code shouldn’t be in the code behind in View.
• There are also other kinds of code that have to go in the code behind any code that's required to have a reference to UI element is inherently view code.

ViewModel Responsibilities

• ViewModel is the main point of MVVM application. The primary responsibility of the ViewModel is to provide data to the view, so that view can put that data on the screen.
• It also allows the user to interact with data and change the data.
• The other key responsibility of a ViewModel is to encapsulate the interaction logic for a view, but it does not mean that all of the logic of the application should go into ViewModel.
• It should be able to handle the appropriate sequencing of calls to make the right thing happen based on user or any changes on the view.
• ViewModel should also manage any navigation logic like deciding when it is time to navigate to a different view.