Beyond the MVP: Extend the MVP model for the Enterprise Application UI architecture

Model-view-presenter (MVP) presents a groundbreaking way of thinking about the UI pattern and is clear that the UI designer should remain independent in the application.

However, there are many different interpretations of the MVP model. For example, some people assume that the MVP pattern clearly represents the UI architecture pattern. This is not entirely true for enterprise-class applications. Enterprise-class applications need to meet many different requirements, involve more stakeholders, become more complex, and rely more on other systems (such as services, other applications, etc.) than other types of UI applications. These unique features require that the UI architecture of enterprise-class applications emphasize flexibility, maintainability, reusability, and implementation consistency, and require that business functions be decoupled from the underlying technology, thereby avoiding reliance on specific products and vendors.

If only the MVP model itself is used as the UI architecture for enterprise applications, there are some problems. Some of the questions are listed below:

Typical enterprise-class applications contain many views, and events that occur in one view may affect other views. For example, clicking a button on one screen may cause a pop-up window to be displayed, while the data for another screen may be updated. Who is responsible for controlling such screen flow logic? Should this be controlled by the pairing representation of each view?

In a service-oriented architecture (SOA), the application UI typically obtains information through services. For example, the UI might need to invoke the generated WCF service client proxy to invoke the WCF service to get the data. Is it a good representation design to call this service client proxy directly? If these services are implemented with different technologies, or if the service model is changed, how should the UI architecture be designed to minimize the impact of these changes on the UI implementation?

Based on this approach, some implementations may use the generated service client Agent model throughout the application. Is there any risk in doing so? If you need a dedicated UI model, which part is responsible for providing mappings between the service client Agent model and the UI model?

These are not new problems, and many other patterns have been introduced to remedy these vulnerabilities. For example, the application controller model is introduced to assume responsibility for controlling the navigation flow.

I think it would be helpful to have these zero-zero MVP extensions discussed together and draw a holistic view of the UI architecture design. Looking at this from an enterprise-level application perspective, you can help the UI architect understand the key components needed for UI design and define a unified pattern to guide the implementation of the UI application.

The term "MVP mode" is used throughout this article, but in practice the original MVP pattern has been replaced by two variants: one is the passive View mode and the other is the supervising Controller mode. These two modes are adapted to different scenarios, and each has its own advantages and disadvantages. The UI architecture described in Figure 1 is based primarily on the passive View pattern and extends it. This is certainly not to say that the UI architecture cannot be based on the supervising Controller model, but only my personal preference.

Figure 1 The UI architecture based on the passive View model