When developing an application, a single page usually contains many submodules. Depending on the platform, these modules are called sub Views and sub Components. In this section, we will discuss how each module interacts weakly with each other in complex business situations.
In the image below, imagine we need to make the content change in View B when we click a button in View A.
Two solutions immediately come to mind.
- View A actively sends notification to View B so View A is connected to View B.
- View B listens for a ColorChanged event and actively pulls updates. In this way, View B became dependent on View A.
Both of these implementations can be implemented without any problems. But let’s consider a complex single-page application, these strong connections would double the complexity of the program. The main idea of MVVM is independence. While View and ViewModel do not feel the presence of each other, neither ViewModel and ViewModel should.
Introducing the Mediator Model
We will use a mediator pattern to resolve this strong dependency by adding a mediator, we will make the Publisher ViewModel tell the mediaitor when its status changes, and the Subscriber ViewModel will respond to the mediator when this request comes.
Now you must define a mediator as MessageAggregator. If this Aggregator is responsible for transmitting the messages it receives, Key is a unique id and Value is a Handler as the message to be transmitted, the basis of Aggregator will be a Dictironary data structure.
Making ViewModel Independent using Mediator
When we bind to the MessageAggregator object as an intermediary, the ViewModelForB becomes a Subscriber object.
When ViewModelForA changes its state, it sends a state message to our Mediator object as Publisher.