Reactive programming and SwiftUI require the MVVM design pattern. 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.
MVVM – Advantages
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 – Responsibilities
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.
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.
