With the clear separation of concerns and better testability, MVVM design pattern is gaining wider acceptance in the developer’s world. There are two common ways to develop your view model classes
1. Write your base view model, other base classes and use them or
2. Use an available framework such as MVVMCross, MvvmLight, etc.
Writing it yourself can take longer due to the learning curve and efforts to write them from the scratch. Available frameworks are large in size and there is a learning curve to learn them. On the top of it, due to large size, they take longer to start. Having multiple layers causes a delay in processing user actions. This can be acceptable in the case of desktop solutions, but not in the case of mobile apps where users expect a faster response.
MvvmAtom provides the middle ground by providing the base classes and wiring for most commonly used MVVM features. That results in a short learning curve with quicker development. Having fewer layers would make it more responsive.
Apart from the above, MvvmAtom provides a unique feature that enables a command to enable/disable itself when a property change occurs in the view model. This avoids having view model track relation between a property and the command(s) that may get affected due to change in its value. It provides clearer centralized decision making in commands rather than sparsely structured decision making in the view model.
Here is how the code would look in a typical framework vs MvvmAtom. (Shortened for brevity)
Typical
public String UserName { set { ... RaisePropertyChanged(); CopyCommand.RaiseCanExecuteChanged(); NavigateCommand.RaiseCanExecuteChanged(); } } public String UserName { set { ... RaisePropertyChanged(); NavigateCommand.RaiseCanExecuteChanged(); } }
MvvmAtom:
public String UserName { set { ... RaisePropertyChanged(); } } public String UserName { set { ... RaisePropertyChanged(); } }
MvvmAtom classes and interfaces are explained here in brief:
AtomViewModelBase
This is a base view model class that provides an implementation of the INotifyPropertyChanged interface. The caller property need not specify its name when notifying listeners. The compiler takes care of extracting the name e.g. set will simply call RaisePropertyChanged();
Apart from it, the base class also has virtual methods that can get called with the view appears/disappears. These methods need to be explicitly called by the View.
AtomCommandBase
This is the base class for commands. This stores the parent view model as a member. So it is accessible during the lifetime. A command will register itself with the view model by calling AddPropertyChangeListener API. Any property change will be notified to the command. It will enable commands to take appropriate action(s).
It provides a virtual method “EvaluateCanExecuteChanged”. This method gets called by the view model when a property change occurs. The inherited class should override this method to make any decision based on the new property(ies) value(s). (E.g. Enable Login button when both UserName and Password have the minimum required length.)
Apart from it, the class provides standard methods to raise the CanExecuteChanged event, perform Execute and CanExecute.
(Note: The class registers itself with the ViewModel using IAtomCommandBase interface. So if ViewModel needs to be unit tested, it can be done using mock commands. This effectively avoiding dependency on the actual implementation.)
IAtomNavigationService
One of the major drawbacks on MVVM design pattern is that a view model cannot navigate a user to a different view as View Model is not aware of the View. In order to provide the functionality, the library provides an interface that specifies the target view model. The App can implement the interface to provide the required functionality specific to the platform.
Also, unit test can implement mock to test navigation functionality.
You can find the NuGet package here:
https://www.nuget.org/packages/MvvmAtom/1.0.0
Code + sample is on GitHub:
Thank you for a good comparison. Your advice helped me a lot.
LikeLike