Presentation Model vs MVP (Passive View)

Question

I'm attempting to learn the Presentation Model pattern, and in my attempt I have become confused on the difference of Presentation Model and MVP - Passive View. Specifically when the Presentation Model does the synchronizing instead of the View. This question is an extension to a previous question on this matter.

Martin Fowler offers the possibility of the Presentation Model doing the synchronizing in his Article.

A Presentation Model that references a view generally maintains the synchronization code in the Presentation Model. The resulting view is very dumb. The view contains setters for any state that is dynamic and raises events in response to user actions. The views implement interfaces allowing for easy stubbing when testing the Presentation Model. The Presentation Model will observe the view and respond to events by changing any appropriate state and reloading the entire view. As a result the synchronization code can be easily tested without needing the actual UI class.

If the Presentation Model is synchronizing, I don't fully understand how it is different than MVP(Passive View). His article about Passive View shows an example that uses synchronization to update the view.

So wouldn't a Presentation Model pattern where the Presentation Model references the View (and syncs) be the same as MVP(Passive View)?

I think that the Presentation Model pattern is part of the MVVM group of patterns rather than the MVP group. Furthermore, when you start to use this pattern with a framework that makes extensive use of binding, like WPF, it becomes a bit clearer how it differs from MVP. — David Osborne
@DavidOsborne According to Martin Fowler, they are different patterns. I'm not disputing that. However, I don't see a difference in Presentation Model with the synchronizing in the Presentation Model (as opposed to the view) and Passive View. If you were to tell me to write a small scale app using Passive View, and then again using Presentation Model with the synchronization in the Presentation Model, I would write it the same way... — Eric
You wouldn't as you're presenter, in Passive View, would contain lots of code that manipulated view. In the MVVM View Model, there wouldn't be any of this kind of code as the view would be bound to the data and behaviour exposed by the View Model. — David Osborne
@DavidOsborne I'm not sure I understand. In the article I referenced in my question and quoted, Fowler states that the Presentation Model can be responsible for synchronizing with the view. MVVM is slightly different in the fact that the view binds to the VM. In the Presentation Model Pattern that Fowler described, there is not binding from the view. The difference between Presentation Model Pattern and MVVM is further explain in this article: blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/… — Eric
Yes, that MSDN article states that MVVM is the Presentation Model pattern that relies on data binding. So I suppose the key remaining difference is how the Presentation Model is designed to closely model the view whereas the MVP Presenter has no such obligation. — David Osborne

Vasudha Vasudha · Accepted Answer · 2016-04-03T03:36:35

Model-View-Presenter is an architecture pattern that defines a structure for behaviour and logic at the UI level. M-V-P separates the logic of the presentation, such as interacting with back-end services and the business layer, from the mechanics of displaying buttons and interface components.

Passive View is a subset of the Model-View-Presenter pattern. Basic Model view presenter diagram

From the outside in, the architecture for Passive View looks something like this:

UI – The User Interface reflects what is going on beneath it by implementing one or more View interfaces
Presenter – The Presenter receives interactions from the UI or Model and updates the Views it is attached to
Model – The model is a facade or black box in our diagram, behind which is a business logic layer and data layer

In a flat architecture we would collect data from the interface, perhaps do some business and data validation, and then save it directly to a database using stored procedures or inline SQL. Defining a data access layer (or data model like entity framework) allows our application to operate on cohesive, defined objects that are meaningful to the application and stored and retrieved consistently. Defining a business logic layer allows us to centralize business rules that operate on entities in our application in a manner that is consistent with the business and internally consistent in the application, minimizing the risk that occurs when making changes to the business flow. Separating the logic of populating inputs and responding to button presses on the UI from the information being communicated to the end user and conceptual responses to their input allows the system to interact with the user consistently across any number of interfaces into the same application.

My example application has several functional and non-functional requirements:

Functional – Display product number, name, list price, and available quantity in tabular format
Functional – Provide a basic search input and button to search product names
Non-Functional – Implement an M-V-P pattern – Obviously the purpose of this whole exercise
Non-Functional – Use a simple model stack that can be easily replaced with a Service-Oriented one at a later time
Non-Functional – Build with the idea that we will later create a Silverlight or WPF front-end
Non-Functional – Make pretty pictures for article

Presentation Model vs MVP (Passive View)

1 Answers