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)?

Answer 1

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