Model-View-Presenter (MVP) is an architecture pattern for the presentation layer of software applications. The pattern was originally developed at Taligent in 1990s and first was implemented in C++ and Java. In MVP, the View and the Model are neatly separated and the View exposes a contract through which the Presenter access the portion of View that is dependent on the rest of the system.
The Model is the component which preserves data, state and business logic; it just exposes a group of service interfaces to Presenter and hides the internal details. The View is the user interface, it receives user’s action and contract to Presenter to achieve user’s need, and then the View responds user by result information. The Presenter sits in between the View and the Model; it receives input from the View and passes commands down to the Model. It then gets result and updates the View trough the contracted View interface.
Illustrates the parts of MVP pattern and how they interact with each other. Since the MVP pattern was put up in 1990s, it has been widely discussed in the area of software engineering; Martin Fowler reported some methods of implementing MVP at his papers and books. However, few wittier have considered how to implement it on concrete program; this process is extremely dependent on experience of developers.
Contrast to traditional presentation layer, the advantage of presentation layer with MVP pattern is based on tree facts:
• The View doesn’t know the Model. Because of this, there is a low coupling between Model and View. It means that if Model or View was changed, another part not needs to modify as long as interfaces are stable. This also stands for the flexibility of architecture and the reusability of business logic in Model.
• The Presenter ignores any UI technology behind the View. According to this, the replacement of UI technology, such as transfer Windows Forms to WPF or to Web Forms, is not need any change of other parts. Even one application could have more than one UI technologies but one Model so that the C/S deployment and the B/S deployment are supported by it at the same time.
• The View is mockable for testing purposes. In tradition, it is impossible to test View or business logic component before another has completed because of the tight coupling between View and business logic. By the same token, the unit testing for View or business logic component is difficult. All of those problems are solved by MVP pattern. In MVP, there is no direct dependency between View and Model. For that reason, developer could use mock object to inject into View or Model so that they can be tested on one’s own.
Front Controller Pattern
android programming,programming for android,programming android apps,mvp pattern,design patterns mvp instructor led training class