Pattern
Model view presenter - make your live easier
The MVC (Model View Controller) patter is a well known object pattern for GUI abstraction, which is taught on every it school. But many programing language don’t support the programmer to use this pattern from scratch.
For example Java, or C# .NET are based on a inheritance topology, the IDE’s create subclasses of the GUI components, resulting in huge source files, which are mixed up with everything. Not to mention that there is no compatibility to other GUI components, e.g. ASP .NET.
Apple with it’s Objective-C / Cocoa framework made a good step in the right direction, the programmer is forced to use the MVC pattern, since the GUI is described in so called NIB files. A controller class contains the code. The NIB file can theoretically be changed without changing the controller.
Also .NET 3.5 has a good answer to this technology, the windows presentation foundation. The GUI is described in XAML files, which are linked to classes. The XAML file could also be exchanged without changing the source code.
These technologies are based on the MVC patter, which still has a string connection between view and model. Further the controller has direct references to the controls within the view. If we want to change a windows forms view with a ASP .NET view, or change the model, the MVL pattern is not flexible enough. This is where the MVP pattern starts to unfold its strength.
The MVP, or more precisely the passive model view pattern is based on three simple interfaces; Model, View and Presenter. View and model are independent entities, only the presenter links the three parts together.
Passive Model View Presenter pattern
Compared to the MVC pattern, the presenter has no direct connection to the GUI controls of the view and the view does not know the model.
The presenter can observe the view and the model, if any changes happens within the model, the presenter gets notified and tells the view what to do. The same procedure happens, if any user interaction happens on the view; The presenter gets notified and has to handle the interaction.
In this case, we can easy implement the view in ASP .NET, Windows Forms, WPF etc. and run it with the same model and presenter.
In some cases, we need a container view, which can maintain any sub views. For this, we extend the passive view pattern with a sub view. The presenter of the container only knows the presenter of the sub view. Sub views are added by adding the presenter of the sub view to the presenter of the container view, model and view are not referenced by the container view presenter.
Since the container view needs no know the sub view, the presenter forwards the sub view to its own view. With this MVP pattern and IoC (Inversion of Control) it’s also possible to use different technologies to implement the views with only one restriction: All views need to be compatible among each other.
MVP - Sub View
The most nice advantage at all is, that we can use dependency injection to create our object structure. To describe this technology would be beyond the scope of this article, but I can provide you some links: