Information Technology Reference
In-Depth Information
In the preceding figure, we can see how the classes inside one single MVP group interact
on the left and how multiple MVP groups interact with each other on the right. We can see
how communication is always managed through an event bus that distributes events to
their relevant listeners, even with multiple MVP groups. This allows the application to
grow exponentially without having to increase the complexity of its already existing com-
ponents. Each MVP group only has to worry about the events that they care about.
This presents a significant improvement over MVP's predecessor pattern, called MVC. It
is similar to MVP, except that it doesn't adopt intercommunication using an event bus.
Without said component, each MVC group (as opposed to MVP) should know any other
MVC group that requires notification of a particular action, and communication between
controllers becomes hard to maintain. In the following figure, we can see an example of
this with only five different MVC and MVP groups. Views and models were removed to
reduce complexity.
Model View Controller versus Model View Presenter intercommunication channels
As you can see, no matter how many presenters exist, or what events they await, existing
presenters that fire said events don't have to change to adjust to a growing component.
With controllers, on the other hand, complexity can grow exponentially.
Now that we understand MVP and its advantages, we will make an example component
using the UberFire framework and the MVP pattern.
